Review staged setup
This is the publish confirmation checkpoint — the place where you review the staged GA4, GTM, Cloud, and Connect setup and confirm it is ready to publish. It's a deliberate, single-action page: read the per-stage status, optionally re-validate everything, then click Confirm setup is ready.
Confirm writes one timestamp to profile_config.publish_confirmed_at. That stamp is the prereq that unlocks Publish. This page has no checks of its own — it reads upstream stage state and records your confirmation. The Re-validate all button runs the upstream stages' automated checks concurrently, but it's a convenience, not a requirement of this stage.
Happy path
- Step 1 — read the per-stage status table; confirm every row is green.
- If any row is stale or attention, click Re-validate all and wait for it to complete.
- Step 2 — click Confirm setup is ready.
- Continue to Publish.
Glossary▶
- Publish confirmation
- The stamp this page writes —
profile_config.publish_confirmed_at = now(). Distinct from the Audit confirmation stamp on the audit run. - Re-validate all
- Convenience button that runs the upstream stages' automated checks (
api+httptypes) in parallel. Skips manual / browser-assisted checks so it doesn't overwrite user attestations. - Confirmation state
- One of: pending, pending_stale, ready, confirmed, stale, drift. See the state table below.
- Drift
- Confirmation is stamped, but at least one upstream stage has dropped below pass-or-stale. The stamp doesn't auto-clear — you have to manually re-validate or clear + re-confirm.
- Build summary
- The "what's being committed" snapshot at the top of Step 1 — GCP project, GTM web and server containers and workspaces, Cloud Run service, tagging endpoint, GA4 browser and server properties, and loader profile. Confirming commits those bindings to this setup.
Not covered on this page: any of the underlying upstream stages (use the per-row links in the status table), the actual publish action (Publish), or the live-traffic confirmation (Publish — Confirm live traffic).
Before you start
- Audit is complete (Audit — Approve).
- All required Build, Cloud, and Connect stages are green; the optional Connect — Preview test can be explicitly skipped.
Review staged setup (decision record)
The decision-record card at the top of the page summarises where confirmation stands. It fills in as you work through the steps below.
| Row | Source | What "done" looks like |
|---|---|---|
| Setup readiness | Step 1 — the rollup of every upstream stage row. | "N of N stages fresh-passing" once all rows are green. |
| Last confirmed | Step 2 — Confirm setup is ready. | Timestamp of the most recent confirmation stamp; "—" until you confirm for the first time. |
| Bindings | Derived from confirmation state. | "Locked to this setup" once confirmed; "Will lock on confirm" when ready; "Pending review" otherwise. |
Confirmation states
| State | What it means | What to do |
|---|---|---|
| Pending | No stamp yet. At least one upstream stage is failing or hasn't been validated recently enough. | Visit the failing stages (linked in the per-step table) and resolve them. |
| Pending (stale) | No stamp yet. All upstream stages are passing but at least one has check rows that have aged past their freshness window. | Click Re-validate all in Step 1; once the stale rows refresh, the state flips to Ready. |
| Ready | No stamp yet. All upstream stages are fresh-passing — the gate is open. | Click Confirm setup is ready in Step 2. |
| Confirmed | Stamp present. All upstream stages still fresh-passing. Publish gate is open. | Continue to Publish. Or click Clear if you need to make build changes. |
| Stale | Stamp present; the upstream stages are still passing but their check rows have aged past freshness. | Click Re-validate all; the stamp stays; the state returns to Confirmed. |
| Drift | Stamp present, but at least one upstream stage has dropped below pass-or-stale. Often happens after a related setting was changed in Google. | Visit the offending stage to fix; re-validate. The stamp itself survives drift, but the "Publish containers →" footer link re-locks until the page returns to Confirmed or Stale. Clear and re-confirm after fixing the upstream stage if you want a clean record. |
1 Review staged setup
Step 1 has no action of its own — it surfaces the state of the upstream stages so you can confirm there are no surprises before stamping. Two panels:
- Build summary — the "what's being committed" half. Lists the GCP project, GTM web and server containers and workspaces, Cloud Run service, tagging endpoint, GA4 browser and server properties, and loader profile. Confirming commits those bindings to this setup; changing a primary selection later clears the confirmation and you'll need to re-confirm after re-running the audit.
- Stage status — one row per upstream stage, with its pass / attention / stale / pending pill and a "validated <X ago>" timestamp. Each stage title links straight to that stage's page so you can spot what's blocking Ready.
Re-validate all is the convenience button at the bottom of Step 1. It POSTs /publish/confirm/revalidate and runs _run_checks_sync for each upstream stage in parallel (one asyncio.to_thread per stage). It updates check_run rows for every api and http check; manual and browser_assisted checks are skipped so it doesn't overwrite user attestations. Returns JSON describing per-stage outcomes; per-stage failures are non-blocking.
If the page is currently Confirmed or Stale, Re-validate all clears your Step 2 confirmation — the inline note below the button says so. The reason: re-validation can change the underlying state, and an attestation made against the old state shouldn't silently carry forward.
2 Confirm setup is ready
Once Step 1 rolls up to Ready, the Confirm setup is ready button activates. Clicking it opens an in-app modal that lays out what attestation commits (the current primary GA4 and GTM bindings get locked for this setup; changing them later clears the stamp). Click Confirm in the modal to write the stamp.
Server-side, the flow is: POST /publish/confirm with action=confirm → recomputes confirmation.state → if "ready", sets profile_config.publish_confirmed_at = datetime.now(UTC) and writes an audit_log row (event_type="publish_confirmed"). Re-renders with stamped state. Idempotent: clicking twice is a no-op.
Once stamped, Step 2 shows a Clear confirmation link. Clear sets publish_confirmed_at = None and writes an audit_log row (event_type="publish_confirmation_cleared"); the Publish gate immediately closes.
Drift doesn't auto-clear
If an upstream stage drops to fail after you've confirmed, the confirmation stamp stays. Publish remains technically accessible. The page surfaces the drift as a banner so you can decide whether to clear + fix + re-confirm, or leave the stamp in place because the drift was a transient API hiccup. This is intentional: it gives you a chance to differentiate "real regression" from "API was flaky for 30 seconds." If you need rigor, you can always clear and re-confirm after re-validating.
Common errors & failure modes
| Symptom | Likely cause | Where to fix |
|---|---|---|
| Confirm button is disabled / page is in Pending state | At least one upstream stage is failing or has no recent check rows. | Look at the per-step status table — fix the failing stage(s). Click Re-validate all if everything looks green but the state doesn't update. |
| Page is in Pending (stale) state — everything looks green but Confirm is disabled | All upstream stages pass but at least one has check rows past the freshness window. | Click Re-validate all; once stale rows refresh the page flips to Ready. |
| Re-validate all returns JSON with per-stage failures, but the page still shows Pending | The named stage's automated checks legitimately failed during re-validation. | Visit that stage's page to see specific check failures and fix them. Re-validate doesn't itself report errors as HTTP failures — it always returns 200 with per-stage detail in the JSON body. |
| Confirmation changed to Drift after I made a setting change | An upstream stage's check transitioned from pass → attention / fail. The stamp persists but the footer "Publish containers →" link re-locks until the page returns to Confirmed or Stale. | Visit the offending stage; fix; re-validate. Or clear + re-confirm to reset. |
| Page shows "already_confirmed" silently after clicking Confirm twice | Idempotent guard — the second click is a no-op since the stamp already exists. | Nothing — this is expected. The state table reflects current truth. |
| After publishing, this page still shows Confirmed — should it auto-clear? | No — the publish confirmation stamp stays in place after Publish, since you might re-publish or re-run Confirm live traffic. | Nothing. The stamp is consumed by Publish but not invalidated by a successful publish. |
Next step
Confirmation unlocks Publish — the action that promotes your staged GTM workspaces to live container versions.
After Go Live
Once the project completes the Go Live cutover, this page stays reachable but renders as a read-only record. The H1 stays "Review staged setup"; the page intro switches to "This setup review is read-only because the project is live. The current stage state remains visible here; use the setup snapshot for the frozen cutover record."
What Step 2 shows in this read-only mode depends on whether publish_confirmed_at was set:
- Stamp present (the normal case — confirmation is a prereq for Go Live): "Publish confirmation was recorded on date. This confirmation is now locked because the project is live."
- Stamp missing (rare; legacy projects that completed cutover under an earlier flow): "This confirmation stage is read-only because the project is live."
The Confirm and Clear buttons are hidden post-live. The Re-validate control is hidden too — POST /p/{slug}/publish/confirm/* endpoints return 409 live_project if invoked directly. Drift review moves to the Changes page; current operating status lives on Health.