GTM Debugging: Why Your Tags Are Not Firing

Olamide Sule, founder of Dolphin Analytics, a London analytics practice that works as Google Tag Manager consultants fixing broken tracking for agency and in-house teams.

A tag that will not fire is something we debug for clients most weeks. It is the kind of fault that leaves you pulling your hair out with data challenges that trace back to one missed trigger condition, and the walkthrough below is the one we run ourselves. Most of the time the tag is fine. The trigger, the timing or the consent state is what is wrong, and Google Tag Manager (GTM) will tell you which if you read it in the right order.

Work from the outside in. Confirm the container is even on the page, then let GTM Preview show you which trigger failed, then confirm the event reached GA4. Skipping to “the tag is broken” is what turns a five-minute fix into an afternoon.

Why won’t my GTM tag fire?

A GTM tag fires only when every condition on one of its triggers is met, so a tag that will not fire nearly always has a trigger problem, not a tag problem. Per Google’s own guide to triggers, triggers are evaluated when code on the page runs, and a tag fires or is blocked once its trigger conditions are met; if any condition fails, or a value is not there yet, the tag stays under Tags Not Fired.

Here are the causes we see most, roughly in order of how often they turn out to be the real one:

1. The container was never published. Per Google’s guide to publishing, versions and approvals, edits live in the workspace until you hit Submit and Publish. A change that works in Preview but not on the live site is this until proven otherwise.
2. A trigger condition never matches. The Page Path, Click Text, Form ID or Custom Event name in the trigger differs from the live value, often by a trailing slash, a query string or a capital letter.
3. The trigger fires too early. The tag reads a dataLayer variable that gets pushed later in load, so at fire time the value is undefined. See the DOM Ready section below.
4. A blocking trigger or exception. Per Google’s guide to firing triggers and trigger exceptions, an exception on the tag, or a “Block” trigger, is quietly stopping it.
5. Consent Mode is holding it. The tag requires a consent signal the visitor has not granted.
6. The wrong container or no container. The GTM snippet is missing from the page, or a second container is loading instead.

The next sections work through how to tell these apart, starting with the tool that answers most of them.

How do you debug a tag in GTM Preview mode?

GTM Preview (Tag Assistant) is the fastest way to see why a tag did not fire, because it shows the exact triggers evaluated on each event and the values GTM saw. Run it before you touch the tag itself, following the same steps as Google’s own preview and debug guide.

1. In your GTM workspace, click Preview at the top right. Tag Assistant opens at tagassistant.google.com.
2. Enter your site URL and click Connect. A new tab loads your site with a debug badge, and Tag Assistant shows a Connected panel. No Connected panel means the container is not loading: check the GTM snippet is in the page <head> and <body> and that the container ID matches.
3. In the connected site, do the thing that should fire the tag (load the page, click the button, submit the form).
4. Back in Tag Assistant, the left timeline lists each event: Container Loaded, DOM Ready, Window Loaded, plus any dataLayer events like gtm.click or a custom purchase. Click the event you expected to fire the tag.
5. Open the Tags tab. Your tag sits under Tags Fired or Tags Not Fired. Click it to expand the firing triggers and see which condition passed or failed.
6. Open the Variables tab for that same event and compare the live value (for example the actual Page Path) against what the trigger expects. A mismatch here is your answer.

If the tag shows under Tags Not Fired with a failed condition, fix the trigger. If it shows under Tags Fired but nothing reaches GA4, the fault is downstream, covered further down.

Is your trigger firing before the value exists? Page View, DOM Ready and Window Loaded

GTM triggers fire at three moments in page load, and picking the wrong one is a top cause of a tag that “fires” but sends empty or missing data. Per Google’s page view trigger documentation, Page View (dataLayer event gtm.js) fires first, the instant the container loads. DOM Ready (gtm.dom) fires once the browser has parsed the HTML. Window Loaded (gtm.load) fires last, after images and other resources finish.

The trap is timing against the dataLayer. Say a tag reads a dataLayer variable your developer pushes halfway down the page. If the tag uses an All Pages Page View trigger, it fires before that push runs, so the variable resolves to undefined and the tag sends a blank field. Confirm it in the Variables tab: the variable reads undefined on the gtm.js event but has a value on a later event.

Three fixes, depending on the value:

• The value is pushed inline, later in the HTML body (a script tag partway down the page, not in the <head>): move the trigger to DOM Ready so it fires after the browser has parsed that value.
• The value is pushed by an action or a script (add to cart, a purchase push after checkout): use a Custom Event trigger whose event name matches the exact string in the dataLayer.push, so the tag fires on that push, not on page load.
• The value depends on something that finishes loading last (an iframe, images, or a third-party script that sets the value once the page is fully loaded): use Window Loaded, which waits until the whole page, including images and scripts, has finished loading.

Is Consent Mode blocking the tag?

Consent Mode can stop a tag from firing, so a tag that never runs for real visitors but works fine in your own tests is often a consent problem, not a trigger problem. Under Consent Mode v2, GTM checks a tag’s consent settings before it fires: a tag that requires analytics_storage or ad_storage is held or redacted until the visitor grants that consent.

Check it in Tag Assistant. Per Google’s guide to troubleshooting consent mode, a tag held by consent shows as blocked, and the Consent tab for the event lists which signals are granted and which are denied. If tags fire only after you accept the cookie banner, consent is working as designed. If they never fire even after you accept, the consent signals are wired wrong: the banner is not updating GTM, or the default consent state is stuck on denied. We walk through that failure in detail in how cookie consent quietly breaks GA4 data.

The tag fires in Preview but the event is not in GA4

A tag firing in GTM Preview only proves GTM sent a request. It does not prove GA4 accepted and recorded it, and the gap between those two is where a lot of debugging time disappears. Confirm the GA4 side directly rather than assuming.

Open GA4 Admin > DebugView (under Property, in the Data display group) while GTM Preview is still connected, since Preview puts the session into debug mode automatically. You can also enable it with the Google Analytics Debugger Chrome extension, following Google’s DebugView guide. Events from a debug session appear in the DebugView stream within seconds. If your event never shows up there, the request is not reaching GA4, and the usual reasons are:

• Wrong Measurement ID. The GA4 tag points at a different property. Check the ID on the tag against the one in GA4 Admin > Data Streams.
• A malformed event name or parameter. A field building the event name from an undefined variable can break GA4’s event naming rules, so check the name and parameters against what the rules allow.
• Blocked downstream. Consent Mode redacted the hit, or an ad blocker or content blocker stopped the request before it left the browser.

If the event does appear in DebugView but not in standard reports, that is a different problem: as Google’s own guidance on confirming data collection notes, standard GA4 reports can take a day or two to process a fresh event. That is reporting latency, not a firing fault. For the wider “GA4 shows nothing at all” case, see Google Analytics not working? Run this check, and for how GA4 counts events in the first place, sessions and events in GA4, explained.

When to call someone

Most tag-firing faults are self-serve: you find the failed trigger in Preview, fix the condition or move it to the right event, and the tag fires clean. A few signs mean you have gone past that point. You have published the change and the tag still fails on the live site, or two containers load on the page and you cannot tell which one owns the tag. Consent Mode or a server-side tagging layer sits between GTM and GA4, so the fault could be in either place and Preview alone will not show you which. The dataLayer changed and nobody who touches the site can say when or why. Or you have worked through every check above, the tag fires clean in Preview, and the numbers in GA4 still disagree with what you expect. That last one is the case where trigger-tweaking never helps: a tag that fires but sends data GA4 quietly rejects, and no amount of retuning the trigger fixes it, because the trigger was never the problem.

That is the work we do for agency and in-house teams most weeks. We've set up hundreds of GA4 properties and Tag Manager containers for agency and in-house clients. If you want to start from the outside, our free scanner Sonar reports the tags, pixels and consent setup it can prove from a single scan of your URL, with no account access. If you already know the fault is inside the account and want someone in GA4 and GTM with you, that is a paid audit: a scoped, five-layer review that names each fault, its impact and the fix. Before either, the GTM audit checklist walks the same ground you can cover yourself.

If your numbers look wrong and you cannot tell whether it is the tag or the tracking underneath it, talking to us is built to point you at the right one.