Go Live

Go Live flips production traffic from going directly to www.google-analytics.com to going through your Cloud Run tagging service first. The destination GA4 property doesn't change — same property, same measurement ID, same reports. Only the route changes.

Cutover finalizes the project and writes a setup snapshot (one per project, ever). Re-cutover is not supported; the canonical path for a redo is to archive this project and create a successor with a new project.

Stage path: Cutover then post-live operations on Health and Monitoring

Rollback Readiness

Cutover captures rollback evidence at multiple points so a regression after Go-Live can be reverted without engineering escalation.

• Pre-baseline row (go_live_baseline with phase='pre') — written at Start cutover. Captures both containers' live containerVersionIds and the client-side snippet URL before the manual change.
• publish_audit_record.web_prior_version_id + server_prior_version_id — captured at Publish, well before Go-Live. The canonical rollback target for "republish the previous container version".
• Setup snapshot — written at Finalize. Frozen JSONB record of every binding, every profile_config field, and every latest check_run. Doesn't change post-rollback; it's a historical receipt.

Rollback procedure for a regression noticed post-cutover. This is the same four-step checklist the app surfaces inline when cleanup fails ("failure mode B") and from Settings → Roll back this Go Live:

1. Revert your website snippet — replace the GTM snippet on your site with the original client-side script that was live before cutover. The app shows the current vs. target snippet inline so you can compare. GSS does not have access to your website source, so this step is user-checked.
2. Republish the prior GTM versions — in GTM, republish the web container's publish_audit_record.web_prior_version_id and the server container's server_prior_version_id as the new live versions. GSS auto-detects when the live containerVersionId matches the prior version; if GTM API can't be read, you can confirm step 2 manually via a checkbox.
3. Verify traffic restored — auto-detected from the same signal as step 2 (live containerVersionId matches pre-Publish state), or rolled into the manual confirm when auto-detect can't run.
4. Archive this GSS project — unlocked once steps 1-3 are complete. The Archive button lives at the bottom of the Emergency rollback checklist. Re-cutover is not available; if you need to redo Go-Live with a different setup, archive the project and start a successor.

Monitoring Expectations

Two layers of monitoring complement each other. Both are needed for production.

GCP Monitoring readiness is set up and operated on the top-level Monitoring page (post-live) and lives in your GCP project. The Health watcher runs in GSS itself and surfaces on the Health page after Go Live finalizes.

Tier 3 Lock Implications

By the time Go Live cutover starts, the project is already Tier 3 locked. Tier 3 is cumulative — it's reached as soon as any of these exist for the project: a test_validation_run, a published mirror_pipeline_workspace, a publish_audit_record, GSS-created Cloud Run bindings, a domain mapping, a go_live_state, or a go_live_baseline row. By Build → Cloud → Connect → Publish you've already crossed several of those thresholds.

Tier 3 means the Tier 2 cascade can no longer fire. Changing primary bindings (browser GA4 property, GTM web container) on Audit Discovery is blocked with a "Setup is locked" panel listing the Tier 3 reasons. The blocking is intentional: Tier 2 cascade would destroy production state, which would have real consequences for live users.

If you genuinely need a different audit selection: archive this project, then create a successor with the new audit. Cloud Run + DNS configuration carries forward only via manual reuse; everything else starts clean.

What changes after Go Live completes

Once Cutover finalizes, the project transitions from setup mode to live mode. The change is a project-state flip, not a layout change — every page you worked through during setup stays at its existing URL and stays accessible. What changes is what those pages do.

Across all setup-pipeline pages (Audit, Build, Cloud, Connect, Publish, Go Live and their sub-pages):

• A green "The project is live" banner appears above the page body.
• All action affordances (Save, Validate, Clear, Confirm, Publish, Start cutover, Finalize, etc.) are hidden. The corresponding mutation endpoints return 409 live_project if invoked directly.
• Each page renders its current state, not the state captured at cutover. The cutover snapshot lives at the dedicated /setup-snapshot URL.

Page-specific post-live shapes worth knowing:

• Go Live cutover — the page heading stays Production Switch; the intro paragraph changes to read "This is the completed cutover record. Completed <date>." All six step bodies render in their completed state. Footer links to Health and Monitoring appear.
• Go Live / Monitoring and Cost Controls — the in-setup stage URL (/go-live/monitoring) redirects to the top-level Monitoring page after Go Live finalizes. The top-level Monitoring page then becomes the operational view for uptime checks, alert policies, notification channels, and Cloud Monitoring links.
• Go Live / Baseline — the in-setup stage URL (/go-live/baseline) redirects to the Setup Snapshot page after Go Live finalizes. The cutover baseline itself is captured during Finalize and is viewable there.
• Publish stages — each becomes a record (confirmation stamp, publish receipt with version IDs, live-test evidence).

Operational work happens on different surfaces post-live:

• Health — current operating status; the daily watcher publishes onto this page.
• Changes — drift detector comparing current state against the cutover snapshot; lets you acknowledge expected drift.
• Settings → Roll back this Go Live — the emergency recovery checklist if cutover needs to be undone.
• Archive — if the project needs structural setup changes, archive it and start a successor. The archived project's snapshot stays available at /setup-snapshot.

Each sub-page guide ends with its own "After Go Live" section describing how that specific page degrades into a record.

Start at: Cutover →