Still Running tags in Google Tag Manager: Here’s how to fix it

Updated: May 12th, 2025

Here’s a problem: you enable Google Tag Manager Preview and Debug mode and see that a certain (or maybe multiple) tags are displayed as “still running”. You refresh the page, but the problem still persists.

Why are your tags in Google Tag Manager “Still running”? There are several reasons:

• You are using an ad blocker
• Google Consent Mode is preventing certain tags from succeeding
• The tag does not have enough time to be properly processed before page redirect/reload
• Content security policy is preventing the tags from completing their tasks

Let’s take a closer look at each of them (and what you can do about it).

Video tutorial

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

Reason #1: Ad blockers

Popular browser extensions like Ghostery, AdGuard AdBlocker, and AdBlock Plus make it easy to block Google Tag Manager. But even if (for some reason) GTM is not blocked, other tracking codes (like Google Ads) can.

So, if you’re using one of the blockers, try disabling them and see whether it helped. Chances are that some browser extension is causing the “Still running” issue.

Other plugins (that are worth checking) are:

• Avira Save Shopping
• DuckDuckGo privacy
• Windscribe VPN
• uBlock Origin

But don’t limit your investigation just to these extensions. There might be more.

Reason #2: Google consent mode is preventing some tags from succeeding

If you have implemented Google Consent Mode (GCM) on your website, it affects how your tags behave and send data to Google (by the way, if you want to learn how to properly implement GCM, I have ~1 hour of video instructions in my GTM course for beginners.

In a nutshell, GCM is a global setting that you can configure on a website. If a visitor does not give consent for analytics_storage, then Google Analytics tags still fire, but the data will be somewhat limited. If consent is given, then the request (with all data) is sent to Google as usual.

But when it comes to ad_storage and marketing tags (like Google Ads), their behavior is different. If a visitor does not agree to be tracked for marketing purposes (read “ad_storage is denied”) and the Google Ads tag fires, it will be displayed as “still running”.

Even though the tag is not displayed as “Succeeded”, it sent the request to Google Ads nevertheless (as a cookieless ping). But if the visitor agrees to marketing tracking on the same page, then the tag sends one more request (this time, with complete data) and then the tag’s status changes to “succeeded”. This is normal behavior if you have configured Google Consent Mode.

How can you know whether you are dealing with Google Consent Mode?

You will have to check the developer tools of your browser. In Chrome, click three dots > more tools > developer tools and open Network Tab.

Refresh the page and check the outgoing requests. If you use Google Ads with GCM, enter “googlesyndication.com”. No requests are found? Enter “doubleclick.net”.  When one of those requests is shown in the Network tab, click it and check if their URLs contain the parameter gcs.

Update: Consent Mode v2 now also contains another parameter called gcd. But to verify this, it’s enough to use gcs.

So, if you see things like gcs, you are dealing with Google consent mode. This means that marketing tags like Google Ads will be displayed as “Still running” in the GTM preview mode until a visitor consents to marketing tracking (by interacting with your cookie consent popup).

That is expected behavior, and there isn’t much you can do about it.

If, on the other hand, the Google Ads tag remains “Still running” even after giving consent to marketing tracking, then your Google Consent Mode is not properly configured. That could be a very lengthy blog post to explain all the details (but as of the moment of writing this blog post, I don’t have one). However, I have very detailed step-by-step instructions and video tutorials about GCM setup in my GTM course for Beginners.

In a nutshell, you must ensure that when a visitor clicks “I agree with marketing tracking” in your cookie consent popup, Google Consent Mode is updated with “granted” permission for ad_storage. Here’s the documentation.

Reason #3: Content Security Policy (CSP)

Website developers might implement a CSP to increase a website’s security level. It helps prevent various types of attacks, particularly cross-site scripting (XSS) and data injection attacks.

Content Security Policy allows website administrators to specify which sources of content browsers should consider valid. The browser then only executes or renders resources from those allowed sources.

Here’s an example:

script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.wordpress.com; style-src 'self' 'unsafe-inline' https://*.wordpress.com; img-src 'self' data: https: http:; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com; connect-src 'self' https://*.wordpress.com; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;

I won’t go into details, but this CSP will allow loading resources from wordpress.com, youtube.com, and other domains mentioned there.

But if a request (on a website) happens to another domain (e.g., googleadservices.com, which is not included), the CSP will prevent that.

The result? Your tag might be displayed as “Still running”. Its execution will not be complete.

For Google Tag Manager, Google Analytics, or Google Ads to work, your developers must update their Consent Security Policy. This documentation provides more information.  Send this link to your developers.

Please note that this cannot be solved directly in Google Tag Manager. You must cooperate with your developers here, and they will have to implement the update directly on the website.

How can you check if you are affected by this? Open the browser’s developer tools, then go to the Console and check the errors there.

If you see something related to “Refused to load….” and “Content Security Policy”, then CSP is preventing your tags from working.

Reason #4. The tag does not have enough time to run properly before the page redirects/reloads

If you fire tags when a visitor clicks a link (and that link then redirects a visitor to another page (or maybe just refreshes the page)), sometimes you might notice that GA or Google Ads tags will be displayed as Still running. This won’t happen always, but you might notice some random behavior when, say, 1 out of 5-10 times, the tag will stay as “still running”.

The reason why this happens is that the tag might not always have enough time to be properly processed by GTM before the page reloads or a user is redirected.

To add even more randomness, sometimes, you will still see that the event (sent by the “still running” tag) will be visible in GA debugview. That’s because the tag might have had enough time to send the request to Google, but GTM did not have enough time to finalize tag execution to change its status to “succeeded”.

If you are facing this situation and it is very important that the click-related event is tracked by Google Analytics as accurately as possible, you might want to consider using “Wait for tags” option in the Just Links click trigger. Giving an additional 1 second (1000 milliseconds) or 2 seconds can increase your accuracy.

In GTM, open your Just Links trigger, click Wait for Tags, and add 1000. Then a new section will appear that asks you “on which pages do you want to activate this trigger”. If your answer is “all pages”, then Page Path contains / is what you should enter.

An example of the Just Links trigger configuration might look like this:

Save the trigger, refresh your GTM container’s preview mode and see if this reduced the number of times when GA tags are displayed as “still running”. If that did not help, try entering 2000 in the trigger.

But this comes with a caveat. When you are delaying the page redirect, you are (potentially) negatively affecting the user’s experience. The waiting time can be a bit longer.

Reason #5. Incorrect configuration of the Microsoft Conversion tag

If you’re working with the Microsoft UET tag to track conversions (and it’s constantly displayed as “Still running”), it’s possible that you misconfigured the tag. I talk more about it in this guide.

But the gist is that you probably entered an incorrect value in the UETQ variable ID field.

Instead, you should enter the name of the variable (ID), like here:

Once you fix the UETQ variable ID field, the “Still Running” issue should go away. For more details, read this blog post.

Sometimes, it’s a false positive

This tip applies to the Google Ads tag. If none of the above-mentioned reasons work for you, go to the browser’s developer tools > Network. While you keep them open, fire your conversion tag and check the network request.

If the gcs parameter is present in the URL, its value is G111, and your request’s response status is 200 OK, then the “Still running” issue might be a false positive.

However, it’s important to remember that this tip is valid ONLY if your request contains gcs=G111 or has no gcs parameter at all.

If, on the other hand, you see gcs=G100, then read tip #2 of this article.

I haven’t found out the reason behind this false positive, but multiple peers in the industry have also seen the same thing (when the tag is displayed as “Still running”, but the request’s status is 200 (which is good)). And their conversion tracking worked fine.

Final words on this “still running” issue

From my experience, these reasons are the most common ones why your tags are displayed as still running in the Preview mode. But if none of the tips worked, let me know in the comments. Maybe you will stumble upon something new that could be used to update this article.