
January 2, 2022
8 Reasons Why a Tag in Google Tag Manager is Not Firing (or Fires When it Shouldn’t)
Updated: January 2nd, 2022.
Note: Even though some screenshots are using the older version of GTM preview mode, that does not change the essence of this blog post and you should still find the answer.
You have configured a tag in Google Tag Manager, enable Preview and Debug mode, try to test it but it behaves not as you expect. Even though you think you did everything right, it just 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 a bunch of 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 out the reasons 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
- #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
- Bonus tip #1 – properly refreshed the preview and debug mode
- Bonus tip #2 – tag is “Still running”
- Bonus tips #3 – Broken Data Layer
- Final words
Video tutorial
If you prefer video content here’s a tutorial from my Youtube channel.
#1. Incorrect trigger
The first thing you should check in order to find out why your tag did not fire in GTM is firing triggers. If you are in a situation where tag did not fire, do the following. Choose an event in the Preview and Debug console’s event stream (left side) and click the tag that behaved unexpectedly.
Scroll down to see all the linked triggers linked to that tag. Take a closer look at the icons next to conditions. If an icon (next to the trigger name) is a green checkmark, that means that this trigger activated the tag (or at least was supposed to). You can also see green and red icons next to every condition of tags. If the condition was met, the icon will be green.
This helps you identify possible reasons why a tag fired (or didn’t). In order 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 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 any of three pages, /pricinc/page1/, /pricing/page2/, /pricing/page3/. If you’re just starting to learn how to use GTM, you might think that 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, therefore, most likely, such a trigger will never be activated because it is not possible for the URL of a website to contain all 3 options (page1, page2, page3).
In this case, you have two options:
- Create 3 separate triggers for each page (not very optimal, especially, when your condition can grow to 10, 20 or more pages) 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 the regular trigger’s ALL conditions are met, the blocking trigger has a higher priority.
In order to find out whether the blocking trigger is the reason why your tag in Google Tag Manager did not fire, follow the same process as in the previous chapter. 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 that 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).
This happens because of the misunderstanding of how blocking triggers (a.k.a. Exceptions) work.
You see, blocking triggers work only against firing triggers that use the same events. Let me explain.
You have a tag that fires on an outbound 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 how 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. Link click trigger can be blocked with link click trigger, pageview trigger can be blocked with 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. You have a tag, it has only one trigger — All Pages.
But for some reason, you see that in the Summary, the tag was fired twice. Why?
This probably has happened because of another feature in GTM called Tag Sequencing. 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 you whether the tag was activated because of tag sequencing.
But you can still figure this out. To do that, go back to your GTM container’s interface and open the tag that fired twice. 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 a bit 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. WTF?
There are no blocking triggers that would have caused that 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 that you think is behaving weird. 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 another 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 the trigger’s 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, a green checkmark is next to a 2nd 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 amount of 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. It will fire only in your live environment (where GTM container snippet does not contain the >m_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 only place where the tag will be fired is live environment (when GTM preview and debug mode is disabled and the GTM code snippet does not contain the >m_preview= parameter).
#8. gtm.blocklist and gtm.allowlist
Developers of your website can limit what kind of tags can you use in your Google Tag Manager container. That can be done 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 certain tag types are added to the gtm.allowList, only they will fire. If certain types are added to the gtm.blocklist, then all of the tag types will work fine except those that are in the gtm.blocklist.
Here is a quick way how to check if you are dealing with blocklist/allowlist in GTM. Open the Preview mode of your GTM container and then see if you have any messages on the left sidebar that push gtm.blocklist or gtm.allowList (older dataLayer setups might use gtm.blacklist and gtm.whitelist. They also work.).
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). Read the description and you will find out that it blocks Custom HTML tags 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 have to 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, then your developer should update the existing array.
Bonus tips
Here are some additional ideas for you to discover further why your tags in Google Tag Manager are not firing properly. I’ll start with the obvious one.
Make sure you have properly refreshed the preview and debug mode
I know. This sounds like one of the Captain Obvious’ tips but this happens more often than everyone would like. So I’ll just say it.
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.
You see your tag being activated in the preview mode but it remains as “Still running”
If you see a tag in the preview console like this, your tag will not properly fire.
One of the most common reasons for this is GA Settings Variable being inserted in the wrong field. Instead of adding it to the dedicated field, some GTM users insert it in the “GA Tracking ID” field. And that is NOT the same.
I’ve written a guide about it here If that does not help, you can also read this guide.
Broken Data Layer
If this happens, you won’t actually 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 GTM container
- Or use dataLayer.push instead
A Tag in Google Tag Manager is Not Firing? Quick summary
In this guide, I have explained a bunch of reasons why your tag might not behave as you’d expect. Maybe it does not fire when you want it to. Or maybe it just keeps firing although you’d like it 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
- Blocking trigger is being used
- Tag sequencing is being used
- Configuration in Tag firing options
- Tag firing schedule is being used
- Firing a tag only in published containers option is enabled
Additionally, it’s a good practice to take a look at whether:
- You have properly refreshed the preview and debug mode
- You have inserted the GA settings variable in the correct field
- The Data Layer is not broken
I have a feeling that I forgot to include something but cannot remember what exactly. So if you notice that there is a missing reason why a tag in Google Tag Manager is not firing, please let me know.

18 COMMENTS
Lots of great info! Are there any other reasons you can think of for scenario #5 to happen? I'm experiencing this with a custom HTML tag that is set to fire on certain pages. Tag Manager preview validates that the condition was met, but the tag still isn't firing.
No, not at the moment.
Thanks a lot!!
I'd been looking for the bug for weeks and thanks to your article I've finally solved it.
:-)
Hi Julius,
As always, have to rely on your content for answers to the questions. However I am a little stuck with this one situation.
I get (entrance) in the URL field when looking at Goal conversions in Analytics. So apparently it is due to Pageview tag not firing before the event tag.
I set priority to Pageview tag to 9999, this still didn't fix the issue.
Now I am considering to adjust tag sequence and I need to understand should I use "Once per event" or "Once per page" ? I just need to ensure the tag is firing correctly for a successful checkout pageview which is /order-received.
Thanks in Advance.
PS: you mentioned to read the next chapter, but I cannot find where it is???
I'm with the same problem
I did a custom HTML tag that is set to fire when DOM is ready. Tag Manager preview validates that the condition was met, but the tag still isn't firing.
Hi, please share the link to you preview and debug mode here. (also, the link to your website where this is happening).
Why is in second example picture screenshot "_triggers matches RegEx (^$|((#|,)7665889_180($|,)))" and what does it do ?
I had situation where similar trigger appeared (I did not set it) and blocked all my events.
Don't worry about that. This is some under-the-hood GTM magic. If your tag was not firing, it was caused by some misconfiguration elsewhere. You cannot control that regex part anyways.
Thank you, this blog helped me!
This is the only useful article I was able to find for this. Thank you!!!
What about when tags only fire in Preview? I've confirmed I've submitted all my changes but the purchase event only fires when I Preview.
Difficult to comment without seeing the actual setup. There might be some delay because of how your website caches JavaScript.
I am having a similar issue. Our tags are firing in preview but none of the data is being aggregated into Google Analytics all of the sudden.
It was all working fine but then stopped one day and I can't figure out why. Do you have any ideas?
Hi Julius,
I have a strange situation with Vimeo and some episerver video blocks. I use the vimeo built in functionality to auto track ever event but now some of the videos have been moved into video blocks instead of being embedded on the page directly. The ones that are embedded on the page directly trigger both the Dom ready and event tag perfectly. But the video blocks only trigger the Dom ready and don't trigger the event tag. Any ideas why this might be happening? To me it seems like they are almost their own mini pages?
Thanks for this amazing post, but I have a case where I don't know the why. The trigger is DOM Ready. The tag is being fired in the preview mode and appear on the right side to the tag name "fired" but below I see the firing status like "failed" and I don't see in tag assistant the tag (Google Ads conversion tracking). Maybe you know the reason. Thanks anyway!
Hi Julius, have you ever seen issues with form submission event tags not firing on IOS or safari browsers? My form submission tags are not firing accurately, when I compare the actual form submissions downloaded from the backend of my site to the numbers in GA. GA form submission event is showing 3 events recorded, but I'm showing 10 form leads in my site. Any help would be appreciated.
Payment Successful URL - /#/ScreenPaymentSuccess?mode=subscribe
I have set up the Google Ads Conversion tag with a 'Page View' trigger and the Debug Mode URL looks something like this- /?gtm_debug=1654957588156#/ScreenPaymentSuccess?mode=subscribe
It seems the URL is considering '#' as parameter because of which my conversion trigger is not firing on payment success page. Can you please suggest a solution for this?