Server GTM container is not receiving requests - reasons and fixes

When you've decided to try server-side tracking and chose Stape hosting (although in the context of this post - it doesn't matter what hosting provider you have), you first create a server Google Tag Manager (sGTM) container. Next, you connect your subdomain to it. Finally, your server preview is up and running. After all this is done, all that's left is to configure the tags.

You start by studying videos and articles on configuring a platform, making changes to your configuration settings within Google Tag Manager, running the preview, and…nothing happens. 

Correctly configuring GTM settings is crucial for effective event tracking and data management. Your server preview is empty; the Google Tag Manager container receives no requests. What should you do now?

Worry not! We have an answer for you.

Sometimes the problem lies in the simplest things that could easily be fixed. Review the following basic issues to check if you're on top of everything.

1. Ensure that the preview server functions properly during the setup process. It can only work correctly in the Chrome browser, so make sure you have it updated to the latest version. 

2. Check that your server GTM container preview is working. When you run it, you should see something like this.

3. In your browser, go to your subdomain and add /healthy to your subdomain link. Everything is set up correctly if you see ok on display. 

4. Start the server container preview; in the add tab, just go to your server container URL and add /test to it. If you see a 400 error on the page - that's fine. You should see this request in the preview.

If the basic checks above pass, technically, everything will be fine with your server container, and the problem with not receiving requests is one of the reasons below.

This may seem silly, but it's worth checking it out first. In the server container URL, make sure to use the exact URL where you are running the sGTM preview to ensure the correct event data is being sent.

The straightforward solution is to send events to the correct URL or run the preview at the correct URL. It's a simple fix that can make a big difference.

GA4 is most often used as a transport mechanism for transferring data from a web GTM container to a server container on the Google Cloud Platform. GCP is necessary for hosting server-side containers due to its robust infrastructure and scalability.

The problem here may be that the GA4 measurement ID you use in your tags may already be used elsewhere and re-initialized with other settings, affecting the tagging server setup on the Google Cloud Platform. It could be, for example, some plugin integrations, inline integration of gtag in code, work of another Google tag in a container, or work from another GTM container if you have several of them on your site.

Open the network dev tool in your browser and activate the preserve log option so you don't lose any events when switching between pages. In the filter, specify the measurement ID of your GA4 for convenience, making it easier to find the necessary requests.

Here is an example of an event that works correctly and is sent to the URL of the server container:

And here is an event that is sent directly to GA due to configuration issues:

Check that all your GA4 events are sent to the URL of your server container, not to google-analytics.com or similar domains.

• Check the code for inline code with gtag initialization or events; it usually looks something like this:

• If you find gtag scripts in your site code, remove them altogether. Check if you have any active plugins or integrations that also send data to GA4. If so, disable these functions.

Ensure no other Google tags with the same measurement ID are in your container. If you have duplicate or legacy containers causing conflicts, knowing how to remove Google Tag Manager snippets correctly from your site code and CMS plugins will help you avoid these overwrite issues going forward.

• Ensure no other Google tags with the same measurement ID are in your container.

Ideally, use a single Google tag with GA4 configured through your GTM container.

The mechanism of the problem is quite simple. Your tag initializes gtag with the setting to send requests to the server_container_url you specify. But after that, additional config is loaded, for example, from gtag, inline code (or any other source), and initialized the same GA4 again but without server_container_url, so requests are sent directly to Google Analytics, and you don't see anything in your server container preview.

Also, if you have this problem, you may have some of the events sent to the sGTM and some directly to analytics. It's just that some event is sent before the Google tag config is overwritten.

Your tags' operation is blocked due to Cross-Origin Resource Sharing (CORS) or Content Security Policy (CSP) settings. 

This is a common problem with resources with advanced security.

These problems are usually immediately visible in the browser console. Open the browser console, reload the page if necessary, and trigger the necessary events.

If you have such problems - you will see several (or many) red errors that will tell you that some request was blocked due to CSP:

Or CORS:

Any of your web tags may be blocked from working because of the same problem.

Contact your developers to add the necessary exceptions to the CORS or CSP rules to unblock your tags. Usually, a few screenshots of the console and a brief description of the problem are enough, but it's also worth sending them the official Google CSP documentation.

Fixing request issues in the server GTM is only part of the solution. Maintaining stable tracking over time is equally important. Many tracking failures can go unnoticed for hours or even days. 

The Monitoring feature helps prevent this by checking your tracking flow and sending alerts when something goes wrong. After receiving alerts, you can react quickly and reduce potential data loss.

1. 1.
   Select the metric and platform you need to monitor. A universal metric is the number of purchases.
2. 2.
   Define thresholds to avoid false positives. Since monitoring often runs overnight, short-term drops in activity are expected. 

A good practiсe is to use a universal metric such as the total number of purchases.

• Define the average expected number of daily purchases via CRM/CMS. Take into account typical fluctuations like weekends, holidays, and nighttime traffic (when conversion volumes are typically lower). 
• Based on the baseline, configure a rule to define a minimum acceptable threshold. If the number of purchases falls below this level, an alert is triggered.

Let's consider, as an example, an alert configuration for Facebook purchases.

Scenario: we checked via CMS that we send an average of 50 purchases per day to Facebook, and we want to be notified if something goes wrong and the number of tracked Facebook purchase events drops below 30 per day.

1. Click Create alert.

2. Add the configurations:

• Alert name.
• Log type: Outgoing Log (since we need to track how many requests were sent to Meta from sGTM container).
• Period: 1 Day (we know the average number per day).
• Event exactly matches Purchase.
• Status code exactly matches 2xx (monitor only purchase requests that were successfully sent to Meta).
• Platform exactly matches Facebook.
• Alert me when there is less than 30 (purchases per day).

3. Click Create.

4. Once the number of purchases is fewer than 30, you will receive a notification on the email(s) you've specified in the Settings tab.

As a digital marketer or web developer, your role in troubleshooting these issues is crucial. When looking for problems with sending data anywhere, you should always pay attention to the browser console and the network tab. There, you can find much more information about how tags and data work than is available just in GTM preview mode. Your insights and actions are key to resolving these issues.