13 Reasons Why a Tag in Google Tag Manager is Not Firing (or Fires When it Shouldn’t)

Updated: April 3rd, 2025 

You have configured a tag in Google Tag Manager, enabled Preview and Debug mode, and tried to test it, but it behaves not as you expected. Even though you think you did everything right, it does not fire. Or maybe it does fire, although it shouldn’t. Why is that happening?

In today’s blog post, we’ll dive into many reasons why a tag in Google Tag Manager is not firing (or maybe it fires when it should not).

Some of the reasons below are pretty straightforward because you can easily find them just by looking at the preview and debug mode. However, in some cases, preview mode does not tell you a thing, which is more confusing.

So buckle up, and let’s start.

If you want to learn more about debugging with Google Tag Manager, you might also find this article useful.

Table of contents

Here’s what you will learn in this article

• #1. Incorrect trigger
• #2. Blocking trigger is added
• #3. Misunderstood Functionality of Blocking Triggers
• #4. Tag Sequencing
• #5. Tag Firing Options
• #6. Tag Firing Schedule
• #7. Fire a tag only in published containers
• #8. gtm.blocklist
• #9. Properly refreshed the preview and debug mode
• #10. Tag is “Still running”
• #11. Broken Data Layer
• #12. Adblockers
• Final words

Video tutorial

If you prefer video content, here’s a tutorial from my Youtube channel.

#1. Incorrect trigger

If the Tag does not fire in Preview mode, then usually there is a problem with your Trigger. Here’s a simple process to follow when this happens:

• Choose an event in the Preview and Debug console’s event stream (left side) and click the tag that behaved unexpectedly (it should be in the “Tags not fired” section).

• Scroll down to see all the linked triggers linked to that tag. Take a closer look at the icons next to conditions. Check if the icon next to the trigger name is a green checkmark.

If yes, this trigger activated the tag (or at least was supposed to). Whether the condition was met or not, every tag condition will be accompanied by a red cross or a green checkmark.

This helps you identify possible reasons why a tag fired (or didn’t). For a tag to fire, ALL conditions in a single trigger must be met. If a tag is linked to multiple triggers, AT LEAST ONE of the triggers must be activated.

A common mistake among beginners is not knowing the relationship between all the conditions in a single tag. Here’s an example.

You want to fire a tag on three pages, /pricing/page1/, /pricing/page2/, /pricing/page3/. If you’re fairly new to using Google Tag Manager, you might think the following trigger is a good choice.

However, it’s NOT. As GTM’s interface instructs, ALL conditions in the same trigger must be met. What would happen here is that this trigger will never be activated. Think about it, how can any website’s URL contain all three options? (page1, page2, page3).

In this case, you have two options:

• Create three separate triggers for each page (not very optimal, especially when your condition can grow to 10, 20, or more pages in the future) and assign all of them to a single tag.
• Use regular expressions in a single trigger, e.g. \/pricing\/page(1|2|3)\/

#2. Blocking trigger is added

Blocking triggers are negative conditions that define when a tag should NOT fire. Even if there are multiple trigger conditions and they are all met, the blocking trigger has a higher priority.

To find out whether the tag is not firing in Google Tag Manager, follow the same process as in the previous chapter.

First, choose the event in the preview console (left side) when your tag was supposed to fire, then click the tag and scroll down to see which triggers were activated.

Even if all the conditions of the firing trigger contain the green checkmark, scroll down to the section “Blocking Triggers”. If you see at least one trigger with all the green checkmarks, then that is the reason why your tag did not fire.

#3. Misunderstood Functionality of Blocking Triggers

On the other hand, maybe you are familiar with blocking triggers and expect they will block a certain tag from firing. However, for some reason, the tag still fired (even though you are 100% positive that all the conditions of the blocking trigger worked).

If this situation arises for you, you’ve misunderstood how blocking triggers (a.k.a. Exceptions) work.

Blocking triggers work only against firing triggers that use the same events. Confused? Let me explain with an example.

You have a tag that fires on the menu link click. Here are the trigger’s conditions:

But on some occasions, you want that to be blocked. If you decide to achieve this with the blocking trigger, the only way it can work is if the blocking trigger uses the same type of trigger, link click (a.k.a. Just Links).

No other trigger will block the link click trigger except the link click trigger.

If you try to block the link click trigger with the Pageview trigger, that will not work. And the same principle applies to all trigger types in GTM.

So the key takeaway here is that you fight fire with fire. A link click trigger can block another link click trigger, a pageview trigger can block another pageview trigger, etc. Learn more about trigger exceptions here.

#4. Tag Sequencing

Now let’s move to a reason that is not displayed in the GTM preview and debug mode (at least for now). Here’s a situation. Let’s say you have a tag with only one trigger — All Pages.

But for some reason, the Summary section in the Preview & Debug Mode shows the tag fired twice. Why?

There is a feature in GTM called Tag Sequencing, which could have caused this. In a nutshell, with tag sequencing, you can create a chain of tags, e.g., if one tag fires, then fire another tag.

Even if the tag’s main firing trigger’s conditions are not met at a certain point, tag sequencing will still fire a tag. And that’s probably why your tag was fired twice:

• First time on a Page view event (due to All Pages trigger)
• And the second time because of the Tag Sequencing.

Unfortunately, GTM’s preview and debug mode is not friendly here. It will not tell whether the tag was activated because of tag sequencing.

But you can still figure this out. To do that, first, head over to your GTM container’s interface and open the tag that fired twice. Then, scroll down to the Triggering section. If the tag is a part of the sequence, it will be displayed there.

Pro tip: if you want to be sure that the tag has fired only once per page, you can use the Tag Firing Option field. Set it to Once per page. To learn more about this option, read the next chapter.

#5. Tag Firing Options

Now, here’s the opposite situation. You see that the tag should have fired multiple times on the same page, but it did only once. You click the event in the preview and debug mode, choose the tag, and see that all the firing conditions were met. But the tag did not fire. Why?

There are no blocking triggers that would have caused this either. So where’s the problem?

Another possible reason for this situation can be this – the tag is set to fire only Once per page.

To verify this hypothesis, go to the tag you think is behaving weirdly. If it is set to fire once per page, you will immediately see that in the tag summary.

If you want to change the settings and fire the tag every time it should, then go to Advanced Settings of that tag and choose “Once per event” in the Tag Firing Options dropdown.

#6. Tag Firing Schedule

Tag Firing Schedule is a GTM feature that lets you set conditions when a certain tag should or should not fire. With it, you can set the start and end date of when the tag should be active. This is useful for time-sensitive campaigns.

If the campaign (and Tag Firing Schedule) has ended,  the tag will not fire even if GTM trigger conditions are met (the only exception with higher priority here is Tag Sequencing).

When Tag Firing Schedule is enabled, in Preview and Debug mode, you will see two blocking triggers:

The first one is for the start date of the firing schedule, and the other one is for the end. In the screenshot above, do you see a green checkmark against the second blocking trigger? This means that the custom firing schedule has ended, and the time-sensitive blocking trigger is activated.

If you expect the tag to fire and the Tag Firing Schedule feature should be disabled, open the tag in GTM’s interface > Advanced Options and disable it.

#7. Fire a tag only in published containers

This feature is useful if you have a very sensitive tag that should fire only in live containers (maybe every time it fires, it charges some money off your business account).

If this option is enabled, the tag will not fire in the preview and debug mode. Also, it will not fire in your testing environments. This feature will allow the tag only in your live environment (where the GTM container snippet does not contain the &gtm_preview= parameter).

How to check if the tag has this option enabled? Open it in the GTM interface > Advanced Options > see the checkbox “Only fire this tag in published containers.”.

As long as it is enabled, the live environment is the only place where the tag will fire (when GTM preview and debug mode is disabled and the GTM code snippet does not contain the &gtm_preview= parameter).

#8. gtm.blocklist and gtm.allowlist

Developers of your website can limit what kind of tags you can use in your Google Tag Manager container. They do this with a feature called blocklist.

Developers can push certain parameters to the data layer, and based on the configuration, GTM tags will behave accordingly. You can learn more here.

In a nutshell, if you add certain tag types to the gtm.allowlist, only they will fire. If the same is done in the gtm.blocklist, then all tag types except those in the gtm.blocklist will work fine.

Here is a quick way to check if you are dealing with blocklist/allowlist in GTM. First, open the Preview mode of your GTM container. Check if you have any messages on the left sidebar that push gtm.blocklist or gtm.allowlist.

If you see a message like this, then this might be the reason why certain tags don’t work. Then, you will need to read this documentation and tell your developers what to add (or remove) to the blocklist/allowlist.

In the screenshot above, class html is blocked. According to the documentation, this will block all customScripts (because it is an alias). The description also mentions how all Custom HTML tags are blocked from firing.
.

And that is not all. If you are facing problems with tags that are using Custom Tag Templates, then read this warning at the end of the documentation:

If you have a blockList, you must ask a developer to add sandboxedScripts to the gtm.allowList array. For example:

dataLayer.push({'gtm.allowlist' : ['sandboxedScripts']});

If you already have something in the allowList, your developer should update the existing array.

#9. Make sure you have properly refreshed the preview and debug mode

I know. I don’t want to sound like Captain Obvious, but this happens more often than everyone would like. But here it is.

If you have made some changes to your tag/trigger/variable, make sure you refresh the Preview and Debug mode first (by clicking the Refresh link in the orange banner) and only then refresh the page you’re working on.

#10. You see your tag being activated in the preview mode, but it remains as “Still running”

If you see a tag in the preview mode like this, your tag might not have fired properly.

I’ve written a troubleshooting guide about it here.

#11. Broken Data Layer

If this happens, you won’t even see new events in the preview mode. Hence no tags will be fired (except on DOM Ready and Window Loaded).

This happens when this dataLayer code snippet is placed below the Google Tag Manager container in the source code.

<script>
dataLayer = [....];
</script>

It rewrites the existing dataLayer on a page and breaks the function that helps Google Tag Manager monitor changes in the dataLayer. I’ve written more about this topic here and here.

A solution to this?

• Ask a developer to move that dataLayer code snippet above the GTM container
• Or use dataLayer.push instead

#12. Adblockers

One of the readers reported that a tag was not firing because of the Adblocker installed in a browser. I don’t have more details but this is definitely something you should verify. If you are using extensions such as Adblock, Ghostery, or anything similar, try disabling it temporarily and see if that works.

If you think that none of your extensions is causing this, there’s still a chance it’s the problem. If I were you, I would try to disable all extensions and see if the problem is resolved. If yes, then one of your extensions is the culprit. You’ll need to re-enable extensions one by one to see which one is causing the issue.

#13. Built-in consent checks

If your setup is using Consent Mode, there’s a chance that you are also using additional consent checks (if Basic Consent Mode is implemented).  You can see them by opening the tag (that does not fire) in the GTM interface, and then you should see the “Consent settings” section.

If in that section, you “Require additional consent for tag to fire”, this might be the reason why your tag does not fire. If consent (say, for analytics) is not given and the tag has an additional consent check for analytics_storage, the tag will not fire until consent is given.

If consent is given after the moment when the tag was supposed to fire, the tag *will NOT re-fire*.

A Tag in Google Tag Manager is Not Firing? Quick Summary

In this guide, I have explained why your tag might not behave as you expected. Maybe it does not fire when you want it to. Or maybe it just keeps firing, although you’d like to do that only once.

In a nutshell, here are the possible reasons why a tag in Google Tag Manager is not firing (or fires unexpectedly):

• Trigger misconfiguration
• A blocking trigger is being used
• You’ve configured Tag sequencing in your tag
• Incorrect configuration in Tag firing options 
• You might have used Tag firing schedule if you’re running a time-sensitive campaign
• Firing a tag only in published containers option is enabled
• Check if you have properly refreshed the preview and debug mode
• See if you have inserted the GA settings variable in the correct field
• Verify that data layer is not broken