Your server-side GTM container works fine until it doesn’t. One Black Friday spike, one viral TikTok, one badly-timed email blast, and suddenly your Cloud Run instance is throttling requests, cold-starting new containers, and quietly dropping events into the void. GA4 shows a suspicious dip. Meta’s CAPI reports fewer conversions than your Shopify orders table. Nobody notices for three weeks.
This post is the guide I wish existed when we scaled our first sSGTM deployment past 200 requests per second. It covers the actual infrastructure work: load balancer selection, dual-stack IPv6, health checks tuned for tagging traffic, and how to test failover without poisoning your production analytics.
Why a Single-Instance Tagging Server Breaks Under Load
The default sSGTM deployment on Google Cloud spins up a single Cloud Run service or a small App Engine setup. Google’s official terraform template gives you three preview servers and three tagging servers behind a load balancer, which is fine for staging. Production traffic exposes four failure modes that most teams don’t discover until they’re bleeding data.
Cold starts. Cloud Run scales to zero by default. First request after idle takes 3-8 seconds while the container spins up. Your gtag.js client will time out and retry, but server-to-server calls from your Shopify app or CRM won’t. Those events are gone.
Regional latency. A single-region deployment in us-central1 adds 180-250ms of round-trip time for users in Sydney. That latency compounds when the tagging server itself calls out to Meta CAPI, TikTok Events API, or a third-party enrichment service. We’ve measured full request cycles hitting 1.4 seconds under load, which breaks synchronous purchase-tracking flows on checkout pages.
Rate limits at the destination. GA4’s Measurement Protocol enforces per-property quotas. Meta’s CAPI has per-token throttling. If your single tagging server batches poorly or retries aggressively, you’ll hit ceilings you didn’t know existed. Distributing traffic across multiple instances with proper backoff logic is the fix.
Event loss during deploys. Every time you push a new container version, that instance drains connections and the next request waits. If you’re doing rolling deploys on a single-region service, you get a ~15-second window per instance where inbound requests pile up.
The fix is horizontal: multiple tagging server instances behind a load balancer, ideally in multiple regions, with health checks that reflect actual sSGTM behaviour rather than generic HTTP 200 checks.
Choosing Your Load Balancer
Three realistic options if you’re running sSGTM on any cloud: GCP Global External HTTPS Load Balancer, AWS Application Load Balancer, or Cloudflare (either as a proxy in front of your origin or via Cloudflare Workers/R2 setup). Each has real tradeoffs.
| Feature | GCP HTTPS LB | AWS ALB | Cloudflare |
|---|---|---|---|
| Native sSGTM support | Yes (official Google docs) | Requires ECS/Fargate or EC2 setup | Proxy only, no native container hosting |
| Dual-stack IPv6 | Yes, at frontend | Yes, at listener | Yes, automatic |
| Global anycast | Yes | No (regional) | Yes |
| Cost baseline (idle) | ~$18/month forwarding rule | ~$16/month ALB | $0 (free tier), $20/month Pro |
| Per-request cost | $0.008 per GB + $0.0075 per LB rule | $0.008 per LCU-hour | Free within plan limits |
| Health check granularity | Custom paths, 1-second interval min | Custom, 5-second interval min | Basic |
| Autoscaling integration | Cloud Run/GKE native | ECS/EC2 native | N/A (edge functions) |
| Session affinity options | Client IP, cookie, header | Client IP, app cookie | Cookie, IP |
If your sSGTM already runs on Cloud Run or GKE, GCP’s Global External HTTPS Load Balancer is the path of least resistance. It integrates with serverless NEGs (Network Endpoint Groups) so you point the LB at your Cloud Run service directly and get automatic scaling. IPv6 is a checkbox on the frontend configuration.
AWS ALB makes sense if you’re running the tagging server on Fargate or EC2 and your data stack already lives in AWS. The tradeoff: ALB is regional. To get global routing you need Route 53 latency-based routing on top, which adds complexity.
Cloudflare is the interesting third option. You keep your origin server (Cloud Run, ALB, wherever) and put Cloudflare in front for DDoS protection, IPv6, and edge caching. The downside is that most sSGTM traffic can’t be cached, so you’re mainly paying for the WAF and IPv6 layer.
Our default recommendation: GCP HTTPS LB with a serverless NEG pointing at Cloud Run in two regions. If cost matters more than latency, single region is fine. If you’re on AWS already, use ALB plus Route 53.
Adding Dual-Stack IPv6 Support
Mobile carriers in the US (T-Mobile), India (Jio), and increasingly across Europe are IPv6-first. When a user’s device only has an IPv6 address, and your tagging server only listens on IPv4, the request routes through carrier-grade NAT64. That NAT layer sometimes rewrites source IPs in ways that break GeoIP lookups and, occasionally, drops connections entirely.
Adding IPv6 to your sSGTM load balancer is straightforward if you’re on GCP. Here’s the terraform snippet we use:
resource "google_compute_global_address" "sgtm_ipv4" {
name = "sgtm-lb-ipv4"
ip_version = "IPV4"
}
resource "google_compute_global_address" "sgtm_ipv6" {
name = "sgtm-lb-ipv6"
ip_version = "IPV6"
}
resource "google_compute_global_forwarding_rule" "sgtm_https_v4" {
name = "sgtm-https-v4"
target = google_compute_target_https_proxy.sgtm.id
port_range = "443"
ip_address = google_compute_global_address.sgtm_ipv4.address
}
resource "google_compute_global_forwarding_rule" "sgtm_https_v6" {
name = "sgtm-https-v6"
target = google_compute_target_https_proxy.sgtm.id
port_range = "443"
ip_address = google_compute_global_address.sgtm_ipv6.address
}
Both forwarding rules point at the same HTTPS target proxy, which points at the same backend service. You only pay for the extra static IP allocation, which is a few dollars a month.
After deploying, add AAAA records to your DNS alongside the existing A records:
# Verify both records resolve
dig sgtm.yourdomain.com A +short
dig sgtm.yourdomain.com AAAA +short
# Test IPv6 connectivity end-to-end
curl -6 -v https://sgtm.yourdomain.com/healthz
curl -4 -v https://sgtm.yourdomain.com/healthz
If you’re on AWS, the process is similar: set the ALB scheme to dualstack in the listener configuration, then add AAAA records pointing to the ALB’s IPv6-enabled DNS name. On Cloudflare, IPv6 is on by default unless you explicitly disabled it.
One gotcha: your tagging server’s request logs will now show IPv6 source addresses. If you have downstream systems (BI tools, fraud detection) that parse IPs assuming IPv4, they’ll break. Test that path before flipping DNS.
Health Checks and Autoscaling That Match sSGTM Traffic
Most guides tell you to point health checks at / or /healthz. That works, but it misses what actually breaks in production.
sSGTM containers can be alive at the HTTP layer while completely failing to process events. Common causes: exhausted outbound connection pools when Meta CAPI is slow, memory pressure from large event batches, or a misconfigured container tag causing infinite recursion. A basic 200 check won’t catch any of these.
Better approach: expose a custom health endpoint on your tagging server that checks internal state. Since sSGTM doesn’t natively expose one, you can add a lightweight sidecar or use the built-in /healthz for liveness and add a separate deeper check via a synthetic monitoring tool.
Here’s a realistic GCP health check config:
resource "google_compute_health_check" "sgtm" {
name = "sgtm-health"
check_interval_sec = 5
timeout_sec = 3
healthy_threshold = 2
unhealthy_threshold = 3
https_health_check {
port = 443
request_path = "/healthz"
host = "sgtm.yourdomain.com"
}
log_config {
enable = true
}
}
The key numbers: 5-second interval, 3-second timeout, unhealthy after 3 consecutive failures. That’s aggressive enough to catch real problems within 20 seconds but not so twitchy that a single slow response takes an instance out of rotation.
For autoscaling, the default CPU-based rule (scale up at 60% CPU) works poorly for sSGTM. Tagging server workload is heavily I/O bound. It spends most of its time waiting on outbound HTTPS calls to GA4, Meta, TikTok, etc. CPU stays low while request latency climbs.
Better: scale on request concurrency or on p95 latency. On Cloud Run:
gcloud run services update sgtm-tagging \
--region=us-central1 \
--min-instances=2 \
--max-instances=50 \
--concurrency=80 \
--cpu=1 \
--memory=512Mi
Setting --min-instances=2 eliminates cold starts at the cost of about $30/month per region for a small container. For most production sSGTM deployments, that’s worth it. The --concurrency=80 value is where we’ve landed after testing: high enough to make good use of each instance’s I/O wait time, low enough that a single slow downstream (looking at you, TikTok Events API) doesn’t crush the container.
Session Affinity and Cookie-Based Client IDs
Here’s where most guides go wrong: they turn on session affinity by default because it sounds safe. For sSGTM, session affinity on client IP will break your GA4 client_id continuity in specific edge cases and add unnecessary hot spots on your backend.
sSGTM is largely stateless. The client_id is set in the FPID cookie on the first request and read from that cookie on subsequent requests. Any instance can handle any request as long as it can read the cookie. Session affinity offers no correctness benefit and can concentrate traffic when one region gets a spike.
Exception: if you’re running custom variables or templates that cache state in memory (some enrichment tags do this), affinity helps warm caches. In that case, use cookie-based affinity rather than IP-based. IP affinity breaks when the same user switches from wifi to mobile data mid-session, which happens constantly.
For geographic routing, GCP’s Global HTTPS LB does this automatically. Users get routed to the nearest healthy backend. On AWS, you need Route 53 latency-based routing pointing at regional ALBs. Cloudflare handles geo-routing at the edge.
Where geography gets tricky: your FPID cookie is set on your custom domain (e.g., sgtm.yourdomain.com). If a user’s request lands in eu-west and later their request lands in us-central, the cookie travels with them and both instances can read it. No affinity needed. But if you’re doing any in-memory dedup for measurement protocol requests (some setups do this to avoid double-firing), that state won’t cross regions. You need Redis or a similar shared store, not affinity.
If you’re building this from scratch and want help thinking through the tag architecture as well as the infrastructure, our GTM service covers both.
Testing Failover Without Corrupting GA4 Data
You cannot test load balancer failover in production without polluting your analytics. Every event that hits your tagging server during a chaos experiment ends up in GA4, Meta, and wherever else you’re forwarding. If half your tests fail, you’ve just added noise to your conversion data.
The pattern that works: run a parallel staging sSGTM container with its own GA4 property (a “shadow” property nobody uses for reporting), then mirror a slice of production traffic to it.
Setup steps:
- Create a second GA4 property called
Production Shadow. Give it its own Measurement ID. Nobody looks at this property except you during tests. - Deploy a staging sSGTM container using the same tag configuration as production, but pointed at the shadow property.
- Put the staging container behind the same load balancer as production, but at a different hostname (e.g.,
sgtm-shadow.yourdomain.com). - Use a traffic mirroring rule to send a copy of ~5% of production requests to the shadow.
On GCP, traffic mirroring at the LB level isn’t native but you can approximate it with a URL map that sends a percentage of requests to a mirror backend. On AWS, ALB doesn’t do mirroring; you’d use VPC Traffic Mirroring at the network layer or a lambda@edge tap.
The simplest approach that works everywhere: add a client-side conditional in your web GTM container that sends duplicate events to the shadow endpoint for a subset of sessions.
// In web GTM: send duplicate events to shadow sGTM for QA sessions
(function() {
var isShadowSession = Math.random() < 0.05;
if (isShadowSession) {
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
'shadow_endpoint': 'https://sgtm-shadow.yourdomain.com',
'shadow_mode': true
});
}
})();
Now you can kill the shadow instance, reroute its DNS, force a container restart, and watch what happens in the shadow property. Compare event counts and event integrity between shadow and production for the same session cohort. When numbers match within a small tolerance during normal operation, you know your test framework is valid. Then break things.
Some checks we run every quarter on the shadow:
- Kill one region’s backend and confirm all traffic routes to the other within 60 seconds
- Trigger a deploy during load and measure event loss
- Force an outbound API failure (Meta CAPI 500s) and confirm retry logic works
- Test IPv6-only routing by disabling IPv4 forwarding rule temporarily
Common Mistakes and Troubleshooting
Mistake 1: Deploying multiple instances but forgetting shared state. If any of your custom templates use in-memory caches, deduplication, or rate limiting, they’ll behave inconsistently across instances. Move that state to Redis or Firestore.
Mistake 2: Health checks that pass while events are being dropped. A /healthz endpoint returning 200 tells you the process is alive, not that it’s processing events successfully. Add real event-flow monitoring via GA4 Debug View or a downstream BigQuery export with freshness alerts.
Mistake 3: Enabling IPv6 without testing GeoIP downstream. Your tag templates may parse x-forwarded-for assuming IPv4 format. Test with an IPv6 client (any modern mobile device on T-Mobile or Jio) and confirm your geographic tags still produce correct country/region values.
Mistake 4: Setting session affinity by default. As covered above, sSGTM rarely benefits from affinity and it can concentrate load. Turn it off unless you have a specific reason.
Mistake 5: Cold starts on min-instances=0. Cloud Run’s scale-to-zero saves money at low traffic but destroys latency for the first request after idle. For any production sSGTM, set min-instances to at least 1 per region, 2 if you can afford it.
Mistake 6: Not versioning your GTM container alongside infrastructure changes. When you deploy a new tagging server version, your GTM container config comes along for the ride. If you roll back infrastructure, you may also roll back tag logic. Keep them independent by pinning the container config version in your terraform/deployment scripts.
Mistake 7: Forgetting to update your Content Security Policy. If you’re proxying sSGTM through a new hostname or CDN, your existing CSP may block requests. Test in a real browser with CSP reporting enabled before flipping DNS.
Mistake 8: Relying on load balancer logs for event debugging. LB logs show HTTP status codes, not event contents. A 200 response can hide a silently dropped event inside a tag failure. Enable request logging in your tagging server container and stream it to Cloud Logging or CloudWatch.
Key Takeaways
- Single-instance sSGTM deployments hit real ceilings once you cross ~100 RPS, including cold starts, regional latency, and rate-limit blowback from downstream APIs like Meta CAPI.
- GCP’s Global External HTTPS Load Balancer is the shortest path for most teams because it integrates natively with Cloud Run serverless NEGs and supports dual-stack IPv6 with a single configuration flag.
- IPv6 support is no longer optional. Mobile carriers on major networks are IPv6-first, and IPv4-only
Share this article