curl is the fastest way to confirm what your tagging server is actually doing. The GTM debug UI shows what the workspace thinks should happen; curl shows what actually happens. The five commands below cover most diagnostic needs.

1. Health check

curl -I https://data.example.com/healthz

200 OK confirms the container is alive. Other responses point at configuration issues.

2. Send a test event

curl -X POST 'https://data.example.com/g/collect' \
  -H 'X-Gtm-Server-Preview: PASTE_FROM_DEBUG' \
  -d 'v=2&tid=G-XXXXXXX&en=test_event&cid=12345'

Posts a synthetic GA4 event. Should appear in the preview pane within seconds.

3. Verify the loader

curl -I 'https://data.example.com/gtm.js?id=GTM-XXXXXXX'

Should return 200 with Content-Type application/javascript. If it returns 404, your Web Container client is not configured.

4. Check CORS preflight

curl -X OPTIONS 'https://data.example.com/g/collect' \
  -H 'Origin: https://example.com' \
  -H 'Access-Control-Request-Method: POST' \
  -v 2>&1 | grep -i 'access-control'

Shows the CORS response headers. If CORS errors are blocking your requests, the missing headers will be obvious here.

5. SSL certificate inspection

echo | openssl s_client -servername data.example.com -connect data.example.com:443 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Shows the issuer, subject, and validity dates of the SSL cert. Useful when "I think SSL is broken" but the browser is being unhelpful about why.

A debug alias worth keeping

# In your shell rc file:
alias sgtm-test='curl -X POST -H "X-Gtm-Server-Preview: $SGTM_PREVIEW" -d "v=2&tid=$GA4_ID&en=test_event&cid=12345"'

Set the env vars once per session, then sgtm-test https://data.example.com/g/collect sends a test event in two words. Worth setting up if you debug containers more than weekly.