Confirm live traffic

This is the final publish step. The previous step published both staged GTM workspaces to live container versions. This page proves that the live containers are actually moving real traffic through your tagging endpoint into the test GA4 property — not just that they parse correctly. GSS polls GA4 Realtime on both properties plus the Cloud Run service health and error logs, then asks you to attest that you've seen live traffic.

The page has two steps. Step 1 (Collect realtime data) runs five concurrent checks against GA4 + Cloud Run and polls every 10 seconds for up to 3 minutes; you can re-run it as many times as you need. Step 2 (Confirm live traffic) is a single attestation click that locks the stage once all five Step 1 checks are passing.

Happy path

Step 1 — click Collect data and open your live site in another tab. Navigate a few pages to drive realtime events.
Wait while the page polls. All five LEDs turn green as page_view + session_start show up in both properties and Cloud Run stays clean.
Step 2 — click Confirm to stamp the stage complete.
Continue to Go Live — Cutover.

Glossary▶

Realtime report: GA4 Data API endpoint (runRealtimeReport) that returns the last ~30 minutes of activity for a property. GSS polls it for both the production browser property and the test server property.
Baseline: The page_view + session_start counts GSS snapshots the moment you click Collect data. Subsequent polls grade delta, not cumulative count — so cached events from before the click can't flip a check green.
session_start: A GA4 auto-collected event that fires once per session (~30 minutes idle). Opening your site in an incognito / private window is the reliable way to force a new session_start during the probe window.
Cloud Run logs window: The check scans ERROR-severity entries in Cloud Logging from the moment you clicked Collect data until now (capped at 60 minutes).
Attestation: The single-click confirmation in Step 2 that stamps publish:live-test complete. Unlocking and re-testing clears the stamp and the Step 1 check rows.

Not covered on this page: reviewing the staged setup (Publish — Review staged setup) or the actual GTM publish (Publish). The browser-probe / DevTools test belongs to Connect — Preview test, not here.

Before you start

Publish is complete — both staged GTM workspaces have been published and the four publish steps are green.
Your live site has the GTM web container snippet that contains the GSS-staged forwarder tag (this is what the previous Publish stage put live).
Google credentials with analytics.readonly and cloud-platform scopes (for the GA4 Data API + Cloud Logging calls).
The ability to drive page_view events — either real users on the site, or you opening it in a few tabs / incognito windows.

1 Collect realtime data

Click Collect data. GSS snapshots a baseline of current GA4 event counts and the click time, then polls the five checks below every 10 seconds for up to 3 minutes. Each subsequent poll grades the delta against the baseline — so events the GA4 Realtime window had already accumulated before the click don't accidentally turn a check green.

Open your site in another tab (or share the URL with a teammate, or open in incognito for a fresh session) and navigate a few pages while the page polls. Each LED turns green the moment its underlying signal first satisfies its pass condition; the row stays green for the rest of the cycle.

You can re-run the probe by clicking Collect data again. Each click resets the baseline and clears the per-row LEDs back to grey, so any cached "pass" from a previous cycle is invalidated.

The five checks

1.1Primary GA4 is receiving page_view events

Confirms your production (browser-side) GA4 property is receiving new page_view events since you clicked Collect data.

Deep dive ▶

What it checks. GA4 Data API runRealtimeReport on the primary (browser-direct) property; passes when the count of page_view events increases versus the baseline GSS captured on the Collect-data click.

What counts as pass. delta > 0 for page_view. The row shows the new count and (in the evidence panel) the baseline + cumulative window count.

Why it might fail or stay pending. Nobody visited your site since you clicked. The browser GA4 tag isn't firing on the pages you visited (cache, ad blocker, broken tag config). GA4 Data API quota or permission error.

How to recover. Open your site in 1–3 tabs (or share with a teammate) and navigate. If a cache extension blocks GA, disable it and retry. Validation errors with a remediation link are surfaced inline in the check row.

1.2Test GA4 is receiving page_view events via sGTM

Same as 1.1 but against the test server-side GA4 property — the one events reach via your sGTM Cloud Run endpoint, not via the browser direct.

Deep dive ▶

What it checks. Same GA4 Data API call, but against the test server property bound on Build — GA4 Properties.

What counts as pass. delta > 0 for page_view since baseline.

Why it might fail. The forwarder tag in the published web container isn't firing. The Cloud Run tagging endpoint is unreachable. The test forwarder is configured to point at the wrong measurement ID. (1.1 passes but 1.2 doesn't → almost always a forwarder / endpoint issue, not an analytics issue.)

How to recover. Check 1.4 (/healthy) and 1.5 (Cloud Run logs) first — they usually point at the underlying problem. If they're green and 1.2 still fails, walk back to Connect — Web Container to confirm the forwarder tag's destination and trigger.

1.3Same session reached both GA4 properties

Confirms session_start appeared in both the primary and test GA4 properties since baseline. Proves both pipelines see the same session, not just isolated page_view spam.

Deep dive ▶

What it checks. Composite of the 1.1 + 1.2 realtime data — delta > 0 for session_start in both properties since baseline. session_id values differ across properties; only presence on both sides is checked.

Why session_start matters. page_view can fire on every navigation within an existing session, so a pre-warmed browser tab could keep 1.1 / 1.2 green even with no fresh user activity. session_start fires once per ~30-minute idle window, so observing a new one on both sides confirms the pipeline carried a real new visit end-to-end.

What counts as pass. Both properties show a positive delta for session_start since baseline.

How to recover. Open your site in an incognito / private window (or close all open tabs, wait 30 minutes, reopen). That guarantees a fresh session_start. If only one side fires session_start, the GA4 tag on the failing side probably has its event filter narrowed in a way that excludes session_start — check the GTM tag config for that container.

1.4sGTM service is reachable (/healthy 200)

HTTP probe of https://<tagging-host>/healthy — same one Google Cloud's uptime checks use to monitor sGTM Cloud Run instances.

Deep dive ▶

What it checks. One httpx.get against the tagging endpoint's /healthy path. Confirms the Cloud Run service is reachable from the public internet right now.

What counts as pass. Status code is 200.

Why it might fail. Cloud Run service is down or scaled to zero with a cold-start failure. Custom domain DNS or SSL broken. cloudrun_tagging binding missing from the project (the check fails with "No tagging endpoint URL bound").

How to recover. Re-run Cloud — Tagging Services + Cloud — Tagging Endpoint to pinpoint where the service is broken.

1.5No errors in Cloud Run logs (since Collect data)

Scans Cloud Logging for ERROR-severity entries on the tagging Cloud Run service in the window between when you clicked Collect data and now. Catches runtime errors that don't show up in /healthy.

Deep dive ▶

What it checks. Cloud Logging API entries.list with a severity=ERROR filter and a resource filter scoped to the tagging Cloud Run service. The time window is "since Collect data" — min(60 minutes, now - baseline_time), so a probe started 30 seconds ago has a 30-second log window.

What counts as pass. Zero ERROR entries in the window.

Why it might fail. The container is throwing exceptions (commonly bad CONTAINER_CONFIG, OOM, downstream GA4 hitting quota). 401 / scope missing → row says "Reconnect Google access". ProjectNotFound → Logging API not enabled on the GCP project.

How to recover. Open Cloud Logging in the GCP Console and read the actual error messages. Most issues show up within the first 5 minutes of logs after a misconfigured tag goes live.

2 Confirm live traffic

Once all five Step 1 checks are green, the Confirm — live traffic verified button activates. Click it to attest that you've reviewed the realtime data and the live test pipeline is working. This writes a completion stamp to the publish:live-test step and unlocks the Go Live stage.

Step 2's card is always visible — the button stays disabled until Step 1 rolls up green, so you can see the affordance you're working toward. Once you attest, the step heading flips to "Live traffic confirmed" with a Confirmed pill and a "Confirmed on <date>" line; the action area swaps the Confirm button for a small Unlock & re-test » link that opens an in-app modal ("Unlock live traffic verification?"). Confirming the modal clears the attestation and the Step 1 check rows so you can re-run Collect data fresh.

Re-clicking Collect data from the attested state is a shortcut for the same thing: it auto-clears the attestation, sets a session flag, and reloads so polling restarts in one click. This is the supported way to re-run the test (for example, after editing a tag in GTM and re-publishing).

Why attestation, not auto-stamp?

The five checks are good enough to be passing yet still miss configuration nuances only you can verify (the right pages were visited, the right GA4 property was queried, no PII leaked into custom dimensions). Attestation is a one-click human sign-off layered on top of the automated checks — comparable to publish:confirm's attestation pattern. Stamps are easy to clear and re-create; the cost of an over-eager auto-stamp would be much higher.

Common errors & failure modes

Symptom	Likely cause	Where to fix
Page-level
Page shows "Complete Publish first" banner	The four publish steps haven't all completed.	Publish — Publish; the banner links straight to the next unfinished step.
"Reconnect Google access" inline on a check row	OAuth scope missing or token expired (most often GA4 Data API or Cloud Logging access).	Click the inline Reconnect link, accept the requested scopes, then click Collect data again.
Step 1 stays amber
1.1 stays pending the entire 3-minute window	No real users on the site during the probe (common for low-traffic / dev sites).	Open your site in 2–3 tabs and navigate a few pages, then let the next poll fire. Or generate test traffic from teammates.
1.1 passes but 1.2 stays pending	Browser-direct GA tag works but the forwarder isn't moving events through the server pipeline.	Check 1.4 + 1.5 first. If they're green, walk back to Connect — Web Container and confirm the forwarder tag.
1.3 stays pending but 1.1 + 1.2 pass	Pages are within an existing GA session — no new session_start has fired.	Open the site in an incognito / private window to start a fresh session, then navigate a few pages.
1.5 fails with "No tagging endpoint URL bound"	The `cloudrun_tagging` binding wasn't carried into this project's connect state.	Cloud — Tagging Services; re-bind and re-validate.
Step 2 confirmation
Confirm button is disabled even though some LEDs are green	At least one of the five checks is not yet pass — the gate is all-or-nothing.	Look at the per-row subtext on the not-pass rows; each carries a one-line remediation hint.
Clicked Collect data after confirming and Step 2 stayed green	This is a transient state — the page reloads after clearing, and the JS auto-restarts polling.	Nothing — the page handles the reset for you.

Next step

Once Step 2 is confirmed, continue to Go Live — Cutover. The cutover flips real browser traffic from your legacy GTM tagging path onto the new first-party endpoint; the live-test you just ran proved the path is ready to carry it.

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 "Confirm live traffic"; the page intro switches to "This live-traffic confirmation page is read-only because the project is live. Realtime evidence remains visible here when it exists; use Health and Changes for post-live verification."

The polling state machine is gated off post-live: no Collect data button, no live event counter, no per-row attest controls, no probe scripts. The Unlock & re-test action is hidden too. POST /p/{slug}/publish/live-test/* endpoints return 409 live_project.

If a project completed cutover without finishing live-test under this flow (legacy projects), the prerequisites-missing branch shows a "Live-test receipt unavailable" banner that redirects the user to Health and Changes. The cutover snapshot at /setup-snapshot still records what was captured at Go Live cutover-success.