- GTM
- Google Tag Manager
- Tracking
- Troubleshooting
GTM Debugging: Why Your Tags Are Not Firing
By Olam Sule · Published 3 Sept 2026
TL;DR
When a GTM tag will not fire, the fault is almost always the trigger, not the tag. Work in order: confirm the container is on the page and GTM Preview is connected, read which trigger failed in Tag Assistant, then confirm the event lands in GA4 DebugView. Consent Mode and firing timing cause most of the rest. We debug GTM setups for clients most weeks.
Olamide Sule, founder of Dolphin Analytics, a London analytics practice that sets up and fixes GTM and GA4 tracking for agency and in-house teams.
A tag that will not fire is the single most common thing we get called in to debug, 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. GTM evaluates triggers against the values present at a specific moment in page load; 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:
- The container was never published. 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.
- 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.
- 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.
- A blocking trigger or exception. An exception on the tag, or a “Block” trigger, is quietly stopping it.
- Consent Mode is holding it. The tag requires a consent signal the visitor has not granted.
- 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.
- In your GTM workspace, click Preview at the top right. Tag Assistant opens at tagassistant.google.com.
- 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. - In the connected site, do the thing that should fire the tag (load the page, click the button, submit the form).
- Back in Tag Assistant, the left timeline lists each event: Container Loaded,
DOM Ready, Window Loaded, plus any dataLayer events like
gtm.clickor a custompurchase. Click the event you expected to fire the tag. - 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.
- 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. 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.
Two fixes, depending on the value:
- The value is in the initial HTML (a data layer set in the
<head>): move the trigger to DOM Ready so it fires after the page renders that value. - The value is pushed by an action or a script (add to cart, a
purchasepush after checkout): use a Custom Event trigger whose event name matches the exact string in thedataLayer.push, so the tag fires on that push, not on page load.
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. 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. 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 sends something GA4 silently drops or files oddly.
- 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: standard GA4 reports process on a delay, so a fresh event can lag by up to a day. 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 the debugging does not end it
Most tag-firing faults are self-serve: you find the failed trigger in Preview and fix it. The ones that are not usually hide in the join between systems, a dataLayer that a developer changed without telling anyone, a consent platform sending the wrong signals, or a tag that fires cleanly but sends data GA4 quietly rejects. When we audit accounts, tags that fire in Preview yet never land in GA4 are the fault we find most, and they are the ones no amount of trigger-tweaking resolves.
That is the work we do for agency and in-house teams most weeks. 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.
Frequently asked
Why is my GTM tag not firing?
A GTM tag fires only when a trigger's conditions are all met on that page, so a tag that will not fire almost always has a trigger fault, not a tag fault. The common causes are a trigger condition that never matches (a Page Path or Click Text that differs from the live value), the container never being published, a blocking trigger or exception, Consent Mode holding the tag, or a firing trigger that runs before the dataLayer value it needs exists. GTM Preview tells you which one by showing the tag under Tags Not Fired with the failed condition.
How do I use GTM Preview mode to debug a tag?
Click Preview at the top right of your GTM workspace, enter your site URL in Tag Assistant and click Connect. A Connected tab confirms the container loaded. Then load the page or take the action that should fire the tag, pick that event in the left timeline, and open the Tags tab: the tag sits under Tags Fired or Tags Not Fired. Click it to see each trigger condition and which value failed, checking the actual values in the Variables tab for that same event.
What is the difference between Page View, DOM Ready and Window Loaded triggers?
They fire at three different moments in page load. Page View (event gtm.js) fires first, as soon as the container loads; DOM Ready (gtm.dom) fires once the HTML is parsed; Window Loaded (gtm.load) fires last, after images and scripts finish. A tag that reads a dataLayer value pushed partway through load will find it undefined if its trigger fires too early, so moving the trigger to DOM Ready, Window Loaded or a Custom Event trigger that matches the push usually fixes it.
My tag fires in GTM Preview but the event is not in GA4. Why?
A tag firing in Preview only proves GTM sent the request; it does not prove GA4 accepted it. Check the GA4 Configuration or Event tag for the wrong Measurement ID (sending hits to another property), a field that builds a malformed event name, or a request blocked downstream by Consent Mode or an ad blocker. Open GA4 DebugView while Preview is connected: if the event never appears there, the problem is between GTM and GA4, not the trigger.
Can Consent Mode stop a GTM tag from firing?
Yes. With Consent Mode v2, a tag whose consent settings require analytics_storage or ad_storage is held or redacted until the visitor grants that consent, so it can look like the tag never fired. In Tag Assistant the tag shows as blocked with its consent state, and the Consent tab shows which signals are denied. If tags only fire after you accept the banner, consent is working; if they never fire even after consent, the consent signals are wired wrong.