Guide 27 · Debugging · GA4 + Tag Manager
Events went missing after a GTM publish: the published version is not the one you tested
A publish ships the workspace as it stands — including a half-finished edit, a paused tag, or a change someone else saved. Check the live version, not the workspace.
After the steps below, the live version is identified by number, the change that broke the events is named, and a corrected version is published and confirmed.
Download the check: the debugging check (JSON) (MD5 e9ecd49c3a3719eee6abf55edcd38728, 485 bytes). It lists the checkpoints from this guide and the worked check, with the figures recomputed. The file was built for this guide and validated structurally — it was not exported from a live container or a live property.
What you need
- The Versions list in Tag Manager. The version numbers, names, and dates — the history of what was published, and when.
- Preview, for the workspace test. To prove the workspace draft works before you blame the publish.
- The date and time the events stopped. From Realtime or DebugView, so the break can be matched to a version.
- The workspace change list. What was changed, by whom, and when — Tag Manager shows the workspace activity.
The trace
The worked check: the figures below were recomputed before publication, and the note under the table shows the working.
| Check | Figure |
|---|---|
| Versions published in the last 7 days | 3 |
| Version live when the events stopped | 14 |
| Events per day before version 14 | 120 |
| Events per day after version 14 | 0 |
| Events per day after the corrected version | 120 |
Three versions were published in the last 7 days, and the events stopped when version 14 went live. Before it, 120 events arrived per day; after it, 0 arrived — 120 minus 0 is 120 events lost per day. The corrected version brought the count back to 120 per day, so 120 minus 120 is 0 events still missing.
- Find when the events stopped. Look at the event count by day. In the worked check, the count was 120 per day, then 0 from the day version 14 was published. A break that starts on a publish day points at the publish, not at the site. Write the date down.
- Open the Versions list and read version 14. In Tag Manager, open Versions and find the version that went live on that date. Read its description and its changes: which tags were added, changed, paused, or deleted. One of those changes is the break.
- Test the workspace in Preview. If the workspace draft still works in Preview — the tag fires, the event reaches DebugView — then the draft is fine and the published version is the problem. If the workspace draft is also broken, the bad change is in the workspace too, and the publish only shipped it.
- Compare the live version with the one before it. Tag Manager lets you compare versions. Read the difference between version 14 and version 13, change by change. In the worked check, the difference was a paused tag: someone paused the GA4 Event tag during testing and published with it still paused.
- Fix it, publish a corrected version, and count the events again. Unpause the tag, or undo the bad change, and publish a new version with a name that says what it fixes. Then count the events per day for the next two days. The count should return to 120 per day. If it stays at 0, the bad change was not the one you fixed — read the version difference again.
Dead ends
DEAD END — THE WORKSPACE WORKS, SO THE PUBLISH MUST BE FINE. Preview tests the workspace draft, not the published version. A workspace that works and a live site that does not means the publish shipped something different from the draft — a paused tag, a half-saved edit, or a change made after the test. Check the live version, not the workspace.
DEAD END — A PAUSED TAG THAT LOOKS DELETED. A paused tag still sits in the container, listed quietly, and its events simply stop. If the tag list looks complete but the events are gone, check the pause state of each tag before you look for anything else.
DEAD END — PUBLISHING A FIX WITHOUT A NAME. A corrected version with no description joins a list of identical-looking versions, and the next person cannot tell which version fixed what. Name the version after the fix, so the history can be read.
End state
The live version identified, the breaking change named in the version difference, and a corrected version published and counted back to 120 events a day. The publish is now a history that can be read, not a mystery — and the next break gets the same treatment.
Sources
- Tag Manager Help — Preview and debug containers — Preview and debug mode testing the workspace draft, and previewing an older version from the Versions list
- Analytics Help — Confirm that you are collecting data — Realtime and DebugView as the same-day checks after a corrected version is published
Checked 11 November 2026. The click paths above are the ones in Google's help pages, opened 11 November 2026. What was run: the publish counts, recomputed — 3 versions in 7 days, 120 events per day before version 14 and 0 after, so 120 lost per day, and 120 per day again after the fix. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.