A tag that refuses to fire is the most common and most maddening problem in GTM, precisely because the cause is almost never where you first look. A calm, ordered check finds it every time. Here is how to debug a tag that will not fire.

Start in Preview, always

GTM Preview mode is the one tool that answers the question directly, showing you, event by event, which tags fired and which did not and why. Before changing anything, reproduce the problem in Preview and watch the tag in the Tags Not Fired section. Guessing without Preview is how people waste an afternoon on a one-line fix.

Check the trigger first

Nine times out of ten the tag is fine and the trigger is the problem. Work through the trigger logic:

  • Confirm the trigger event actually occurs, visible in the Preview event stream.
  • Check every condition on the trigger, since one mistyped value stops it matching.
  • Watch for a blocking (exception) trigger silently overriding the firing trigger.
  • Verify the trigger type matches reality, for example a History Change trigger on a single-page app rather than a Page View.

Confirm what is actually published

A surprising number of not-firing tags are firing perfectly in Preview and simply were never published. Preview reflects your workspace, not the live site, so a change stays invisible to real users until you publish the container. Check the live version number against what you edited.

Rule out consent and timing

Two subtler causes remain. If you use consent mode, a tag set to wait for consent will not fire until the user grants it, which looks like a broken tag but is correct behavior. And a tag that depends on a data layer value can fire before that value exists, so confirm the value is present at the moment the trigger runs.

// In the browser console, see what the data layer holds and when
window.dataLayer.forEach(function (entry, i) {
  console.log(i, entry);
});

Isolate, then fix

If the trigger fires, the container is published, and consent is granted, but the tag still fails, narrow it down. Temporarily simplify the trigger to All Pages to prove the tag itself works, then add conditions back one at a time until it breaks. That binary search points straight at the faulty condition instead of leaving you guessing.

Read the tag's own errors

Sometimes the tag fires but fails, which looks like success in Preview until you look closer. Open the browser network tab and find the request the tag sends: a 4xx or 5xx response, or a request that never goes out, tells you the tag ran but its configuration or destination is wrong. A GA4 tag with a mistyped measurement ID fires happily and sends data nowhere useful, so confirm the request actually reaches the vendor, not just that the tag showed as fired.

When it fires but the data is wrong

The trickier case is a tag that fires correctly and carries the wrong values. This is almost always a variable problem: a data layer key that is empty at fire time, a lookup that missed, or a field pulling from the wrong source. Inspect the tag's variables in Preview at the moment it fires, and check each one holds what you expect. A tag firing on schedule with garbage inputs is worse than one that does not fire, because it looks fine while corrupting your data.

A tag that will not fire feels maddening only because the cause hides from where you look first, and Preview drags it into the open. Reproduce it in Preview, interrogate the trigger, confirm you actually published, rule out consent and timing, then isolate by simplifying. Work that order and the one-line fix stops hiding, and the tag fires exactly when it should.

Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.