← lior-seats.github.io  ·  September 2026

I calculated what common staging environments actually cost when left running 24/7 — the numbers are surprising

Real cloud pricing, real utilization math. Here's what your staging infra is actually costing you.

It started with a Slack message from our ops lead: "Why is our AWS bill up $200 this month?"

After 20 minutes of digging through Cost Explorer, I found it: three staging environments — API, frontend, and workers — all running continuously since the last sprint planning session. Nobody had touched them since the previous Thursday. It was now Tuesday.

I decided to properly calculate what "always-on" staging environments actually cost, using real public cloud pricing. I also wanted to understand how much of that time they're actually being used. The results were worse than I expected.

The methodology

I pulled public on-demand pricing from AWS, GCP, Fly.io, Heroku, and Render as of September 2026. No reserved instances, no committed-use discounts, no EDP contracts — just the published hourly rate a new user would pay.

For utilization, I used a realistic "active developer workday" model: a staging environment is actually being used when someone is actively deploying to it or running a QA session against it. That works out to roughly:

Active hours per month:
  8 hours/day × 5 days/week × ~2.6 weeks = ~105 hours

Total hours in a month: 730 hours

Utilization: 105 / 730 = 14.4%
Idle time:   86%

That 86% number is the uncomfortable one. And it assumes every weekday has active usage — in practice, most staging environments have significant idle stretches even during the week.

The data: per-environment monthly cost

Here's the full breakdown by provider and instance type, for a single staging environment:

Pricing sourced from public AWS, GCP, Fly.io, Heroku, and Render pricing pages, September 2026. On-demand / pay-as-you-go rates, no reserved pricing applied. GCP Cloud Run minimum-instances billing used for always-on configuration. Waste calculated at 86% idle (105 active hours / 730 total hours).

The real number: multiply by your service count

One environment is annoying. But most teams don't have one staging environment — they have one per service. A typical microservices team with 3–5 services each needing staging infra:

What "idle" actually looks like in practice

I pulled deployment and traffic logs from a few projects to understand what staging environment utilization actually looks like during a typical sprint. The pattern is consistent:

Monday 9am     → deploy new branch, run smoke tests (2h)
Monday 11am    → developer done, moves to feature work
Monday–Friday  → environment sits running, waiting
Thursday 2pm   → QA session (3h)
Thursday 5pm   → QA done, environment still running
Friday–Sunday  → environment runs all weekend, zero traffic
Monday 9am     → repeat

The environment isn't completely unused — it's just only needed in bursts. The rest of the time it's running at near-zero utilization, burning the same compute cost it would during active use.

This is the key difference between staging and production. Production environments need to be available because real users hit them at unpredictable times. Staging environments have predictable, human-driven usage patterns. They're needed when developers and QA are at their desks, not at 3am on a Saturday.

Why existing solutions don't fully solve this

There are platform-level sleep features, and they help — but only within their own ecosystem:

The gap is teams running infrastructure on AWS ECS, GCP Cloud Run, or bare EC2 — which is where most serious staging environments live. Platform-specific sleep features help Fly and Railway users, but if you're on AWS or GCP, there's no first-party "hibernate my staging environment on a schedule" button. You're either writing custom Lambda functions and EventBridge rules, or you're leaving it running.

The other issue: waking environments back up needs to be fast and reliable. If stopping an environment means a 10-minute cold start the next morning, most teams will just leave it running to avoid the friction. The "saved cost vs. resumed productivity" tradeoff has to actually work.

The math summary

These numbers don't include associated costs that also run 24/7: RDS instances for staging databases, ElastiCache clusters, load balancers, data transfer, NAT gateway fees. Add those in and the real waste number for a mid-size team is often 2–3× the compute figure alone.

Calculating your waste: start here

Conclusion

The core finding is simple: staging environments follow human work schedules, but cloud billing doesn't. A compute instance costs the same whether a developer is actively deploying to it or it's sitting idle at 2am on a Sunday.

For teams on AWS ECS or GCP Cloud Run, there's no easy built-in answer. The options are: pay the full 730-hour rate, maintain custom automation to stop/start environments on a schedule, or accept that this is a known inefficiency and move on.

I think the "known inefficiency" category is where most teams land — not because they've decided it's the right call, but because the solution they'd need to build feels like yak-shaving when there's product work to do.

The first step is knowing your actual number. Once you can see "$78/month in pure idle compute," the tradeoff calculus changes.

Pricing data sourced from public AWS, GCP, Fly.io, Heroku, and Render pricing pages as of September 2026. On-demand rates; no reserved or committed-use pricing applied. Utilization model assumes 8-hour active workdays, 5 days/week, ~2.6 weeks active per month (105 hours). Actual utilization varies by team.

← lior-seats.github.io  ·  IdleDown waitlist