We Reviewed a Year of Server-Side Container Costs, Here's What We Found

I pulled a year of Cloud Run billing across four client server-side GTM containers to answer a simple question: did the original cost estimates we gave at project kickoff hold up. They didn't, on any of the four, and the gap had the same shape every time — underestimating baseline instance cost and overestimating how much request-based pricing would dominate the bill.

The pattern across all four

Every initial estimate focused on cost-per-request, because that's the number vendors and Google's own pricing calculator make easiest to model. What actually drove the bulk of ongoing cost was the minimum instance configuration needed to avoid the cold-start problems we'd learned about the hard way elsewhere — keeping even one or two instances warm around the clock costs real money every month, regardless of how much actual traffic comes through, and that baseline cost barely shows up in a 'cost per million events' pitch deck slide.

Server-side tagging cost isn't dominated by how many events you process. It's dominated by how many instances you have to keep warm just to avoid the latency problems you'd get from processing zero events.

What we found, concretely

• Baseline warm-instance cost accounted for 55-70% of total monthly spend across all four containers, far higher than any of us had modeled at kickoff.
• Traffic-driven request costs scaled roughly linearly with volume, as expected, but were a smaller share of the total than anticipated.
• One client's container was running a minimum instance count left over from a launch-day fix, never scaled back down once traffic normalized — pure waste that went unnoticed for months.
• Logging and monitoring costs, treated as an afterthought in every original estimate, were a non-trivial line item on their own by the one-year mark.

The actual recommendation that came out of this review: budget for baseline instance cost as the dominant line item from day one, treat request volume as the secondary driver, and schedule a quarterly review of minimum instance settings specifically, since they're the setting most likely to be bumped up during an incident and never revisited once the incident's over.