Back to notes

October 3, 2026 · 6 min read

What Broke During a Server-Side GTM Migration at Scale

Migrating a high-traffic property to server-side GTM exposed cost and latency problems that never showed up during the pilot on a low-traffic page.

PostmortemServer-Side GTM

We piloted a server-side GTM migration on a single low-traffic landing page for two weeks. Everything looked clean: low latency, predictable cost, no dropped events. Three days after rolling it out site-wide on a property doing several million monthly sessions, the Cloud Run bill for the month was already projected to be nine times the pilot's extrapolated estimate, and p95 latency on the server container had crept up enough that a few downstream vendor timeouts started appearing.

Why the pilot didn't predict this

A single low-traffic page never exercises concurrency. The pilot ran comfortably within the minimum instance count we'd configured, so cold starts and autoscaling behavior under real concurrent load simply never got tested. At full site traffic, request bursts during peak hours triggered scale-up events the autoscaling configuration wasn't tuned for, and the default container memory allocation turned out to be undersized for the actual payload processing happening in the transform logic, causing some requests to run slower under memory pressure than our pilot numbers suggested.

A pilot on low traffic tells you the logic works. It tells you almost nothing about cost or latency at scale, and treating it as a scale proof is where this kind of migration goes wrong.

What we changed

  • Increased minimum instance count to eliminate cold starts during business hours, accepting a higher baseline cost in exchange for predictable latency.
  • Right-sized container memory after profiling actual payload processing under realistic concurrent load, not pilot-level load.
  • Added CPU and memory-based autoscaling triggers tuned to the real traffic pattern instead of the platform defaults.
  • Built a cost-per-million-events dashboard before the full rollout next time, so cost scaling is visible before it's a surprise on an invoice.

The migration itself was the right call for this client — the pipeline ownership benefits were real once it stabilized. But I no longer sign off on a full rollout based on a low-traffic pilot alone. The pilot proves the logic. Scale proves the infrastructure, and those are two separate tests that deserve two separate sign-offs before a full migration goes live.