Check tagging server reachability

Verification goal

What are we trying to verify?

A tagging server has been provisioned, the tracking domain has been connected, and the GTM server container has been configured. But is the infrastructure actually reachable, and is the correct server container running there?

Before you start troubleshooting clients, tags, or the client-side configuration of a server-side tagging setup, it is worth answering this question.

In practice, this takes two steps: opening Preview for the Google Tag Manager server container and sending a unique test request through the intended tracking endpoint.

To verify basic reachability and routing up to the server container, ask this question:

Is the intended tagging server reachable, and is the expected Google Tag Manager server container running there?

You can answer this question independently of the client-side tracking configuration.

Troubleshooting

If Preview or the test request does not work

If Preview does not start correctly or the test request does not appear there, narrow down the problem step by step.

The next troubleshooting steps depend on how the tracking endpoint is connected. For a tracking domain, check DNS resolution and the direct connection to the tagging server. For a same-origin setup, focus on whether your website infrastructure forwards the intended path correctly.

Check the health endpoint first

In both cases, the first step is to check the health endpoint through the same tracking endpoint that will later receive the tracking requests.

For a tracking domain, for example:

https://collect.example.com/healthy

For a same-origin setup, for example:

https://www.example.com/metrics/healthy

You can also check both variants from the command line:

curl -fsS 
  https://collect.example.com/healthy

curl -fsS 
  https://www.example.com/metrics/healthy

A successful request returns only:

ok

-s hides the progress meter, -S keeps error messages visible, and -f treats HTTP status codes of 400 or higher as errors. For this test, an error message, an empty response, or any response other than ok is not a successful result. Google documents /healthy as an available health endpoint for the tagging server. See Google: Set up server-side tagging with Cloud Run and the Google manual setup guide.

If the endpoint responds as expected, the tagging server application is generally reachable.

You now know that:

• the endpoint can be reached;
• the HTTPS connection works;
• the request reaches the tagging server infrastructure;
• the tagging server application responds.

This makes the health check a useful first troubleshooting step.

What /healthy does not tell you

A successful health check shows that a functioning tagging server application is reachable at the endpoint. It does not tell you which Google Tag Manager server container or container configuration is running there.

For example, /healthy does not reveal:

• which container ID is being used;
• which container version is published;
• which specific configuration was loaded.

This is why Preview combined with a unique test request is the better starting point. It checks more than whether any tagging server application responds: it connects the test to the specific server container you want to verify.

Same origin

Troubleshooting a same-origin setup

In a same-origin setup, the tracking endpoint sits under a path on the website, for example https://www.example.com/metrics. In this case, DNS and TLS initially belong to the website address. A reachable website therefore does not prove that the tracking path is being forwarded correctly to the tagging server.

Google distinguishes between a subdomain and a same-origin deployment under a website path when using your own domain. See Google: Custom domain configuration.

1. Open the website
2. Check the health endpoint under the tracking path
3. Check routing / reverse proxy
4. Check the server URL selected for Preview

Open the website and tracking path separately

First check whether the website itself is reachable. Then request the health endpoint under the intended same-origin path:

https://www.example.com/metrics/healthy

You can also compare the two from the command line:

curl -sS -o /dev/null 
  -w 'Website: HTTP %{http_code}n' 
  https://www.example.com/

curl -fsS 
  https://www.example.com/metrics/healthy

For the website, expect the status code from its normal configuration, often 200 or an intentional redirect. The health endpoint under the tracking path must return ok.

If the website works but the health endpoint under /metrics does not, the problem is probably not the website’s general DNS resolution. In that case, check the routing between the website infrastructure and the tagging server.

Conclusion

Can Preview for the expected server container be started, and does a unique test request sent through the intended tracking domain or same-origin path appear there?

If so, basic reachability and routing to Preview for the intended server container have been verified at the time of the test. This does not verify continuous availability, redundancy, scaling, or the business logic of the tag configuration.

If not, first check the health endpoint through the affected tracking endpoint. For a tracking domain, continue with DNS, TLS, and the tagging server configuration. For a same-origin setup, check website reachability separately from the routing or reverse proxy to the tagging server.

This lets you narrow down basic connection and routing problems before moving on to the rest of the server-side tagging implementation.