When GTM stops firing tags and nobody noticed
Google Tag Manager is the most common way agencies deploy tracking, and also one of the most common points of silent failure. A GTM tag that stops firing looks exactly like a GTM tag that is firing, until you start looking at the data and realize events stopped arriving weeks ago.
This post covers why GTM tags silently disappear and the detection patterns that catch it fast.
The failure modes, ranked
1. Someone published a container version with a disabled tag
This is the most common. A new workspace was created, changes were staged, someone accidentally disabled a tag (or paused it), and then the workspace was merged and published. The tag still exists in the container, it's just not firing.
How to detect: in GTM, go to the published container → look at the tag list and filter by "Paused" or "Disabled." Active tags should all be green.
How it happens: GTM's UI makes it very easy to pause a tag while testing, and very easy to forget to re-enable it before publishing.
2. Trigger references a data layer variable that no longer exists
A theme update or platform migration changed the data layer structure. Your trigger was looking for event: 'purchase' but the site now pushes event: 'ga4_purchase' or event: 'order_complete'. The tag still exists, the trigger still exists, they just never match anymore.
How to detect: open GTM Preview mode, walk through a test checkout. Watch the data layer events in the left pane. Compare event names and custom data against your tag triggers.
Common culprits: Shopify changelog updates, WooCommerce plugin version changes, any migration between e-commerce platforms.
3. Tag is firing but sending to the wrong property
The tag fires, you see it in Preview mode, you're happy. But the Measurement ID or Pixel ID inside the tag config is pointing at an old property that your team stopped using months ago. Data is being collected, into a graveyard property nobody looks at.
How to detect: click into each tag's config and compare the ID to the currently-active property in GA4/Meta Business Manager/etc. Easy to miss if you have many similar tags.
Common culprits: migrations, agency handovers, new property creation without cleanup of the old tags.
4. Consent Mode v2 blocking everything
If you implemented Consent Mode v2 (required in the EEA/UK) and your CMP isn't setting consent states correctly, every consent-gated tag is blocked. From GTM's perspective the tag is "firing" (the trigger matches) but it's waiting on a consent state that never gets granted.
How to detect: in GTM Preview mode, look at the Consent State section. ad_storage and analytics_storage should transition from denied (default) to granted after consent. If they stay denied, your CMP integration is broken.
Common culprits: CMP config change, CMP plugin update, default consent states misconfigured.
5. CSP header tightened and blocked GTM
A security audit (or a WAF/CDN config update) added a strict Content Security Policy that doesn't allow www.googletagmanager.com. GTM fails to load entirely.
How to detect: DevTools → Console → look for CSP violation errors. Or DevTools → Network → filter "gtm", if you don't see the container load, CSP or adblocking is the cause.
Common culprits: Cloudflare security rule change, hosting provider security update, Nginx/Apache config deploy.
6. GTM script loads but gtag.js doesn't
GTM itself loads fine, but the tag inside the container that actually initializes gtag.js fails. This can happen if the GA4 Configuration tag is paused, or if the Measurement ID field is empty, or if an included variable returns undefined.
How to detect: in DevTools → Network → filter "google" → you should see calls to both googletagmanager.com/gtm.js?id=GTM-XXXXX AND googletagmanager.com/gtag/js?id=G-XXXXXXXXXX. Missing the second one means GTM loaded but GA4 didn't.
7. Permission issues after agency handover
A client revoked (or didn't grant) the agency's GTM access. A new team member was added without publish permissions. An old user was removed and took their "Publish" permission with them. Tags exist but nobody can deploy new ones or fix broken ones.
How to detect: Admin → Container → User Management. Verify at least one person on the account has Publish permissions.
The symptom cascade
GTM failures rarely cause obvious page-level errors. What you'll see instead:
- Analytics data gradually decreases (as the proportion of users with ad blockers stays constant but your baseline drops)
- Meta ads ROAS reports drop with no corresponding real-world performance change
- Google Ads conversion volume declines in a way that doesn't match other signals
- A/B test tools stop recording variants (if they're configured via GTM)
By the time you notice the downstream symptoms, you've usually already lost 1-4 weeks of data.
The detection pattern that works
Monitoring at the script level catches GTM failures faster than monitoring at the analytics level. Here's why:
- Analytics-level monitoring ("did GA4 receive events?") requires waiting for the analytics reporting pipeline. Minimum detection time: 24 hours for most metrics.
- Script-level monitoring ("is GTM loading? Is GA4 script loading? Are tracking cookies being set?") fires within minutes of a scan. If GTM disappears at 9:03, a scheduled scan at 10:00 detects it.
Tracefox's approach:
- Every scheduled scan verifies GTM container is loading from the expected URL
- Every scan records which child tags loaded (GA4 config, Meta Pixel, Google Ads tag, etc.)
- Disappearance of any previously-present script triggers a HIGH severity alert
- Cookie drift detection catches cases where the script loads but the tag silently fails to set cookies
On a site that loaded GTM-ABC123 yesterday but isn't loading it today, you get an alert with before/after evidence within minutes of the next scan.
A pre-publish checklist for GTM changes
Before you hit "Submit & Publish" on any GTM container change, run through:
- [ ] Preview mode test: walk through key user flows (homepage, product, cart, checkout, thank-you) and verify all tags fire
- [ ] Consent check: test with consent granted AND consent declined, verify consent-gated tags behave correctly
- [ ] Cross-browser: at minimum test Chrome and Safari, consent and ITP behavior differs
- [ ] Mobile viewport: some tags have triggers that fail on mobile
- [ ] Verify no duplicate tags were accidentally created (common with copy-paste)
- [ ] Check tag permissions on any new tag (a custom HTML tag with no permissions won't fire)
- [ ] Review workspace changes one last time before publishing
Five minutes of checklist prevents the 40-minute diagnostic session three weeks later.
When to rebuild the container vs patch it
Sometimes GTM containers accumulate cruft: paused tags from 2021, triggers that reference variables that no longer exist, tags pointing at old properties, consent states configured for a CMP you switched away from.
Warning signs that rebuilding is cheaper than patching:
- Container has 100+ tags and nobody can name what half of them do
- Multiple conflicting consent states being set
- Mix of
gtagdirect calls and GTM-managed tags - Migration leftovers (old GA3 tags still present alongside GA4)
For these cases, it's often faster to create a clean new container, migrate only the actively-used tags, test thoroughly, and cut over. You'll lose a week of agency time but save months of ongoing pain.
The TL;DR
GTM tags disappear silently. The detection latency matters more than any other factor in cost. Manual audit catches it in weeks; analytics-level monitoring catches it in days; script-level monitoring catches it in minutes.
For most agencies, automated script monitoring is the right layer to add, it doesn't replace your periodic audit, but it closes the time window between audits from weeks to minutes.
Catch GTM failures before they cost a month of data. Start Tracefox free, automated monitoring of every script on every client site, with Slack alerts the minute a tag disappears. Designed for PPC agencies and SEO agencies.