Staging and preview environments exist to test software before it reaches production. They're useful during working hours, during active development cycles, and when QA is actively running test scenarios. They are not useful at 3am on a Saturday. They are not useful over a three-day weekend. They are not useful while the engineer who created them is on vacation.
But they run anyway. Continuously. Because that's the default.
Cloud pricing for compute is simple: you pay for the instance while it exists, whether or not it receives requests. An EC2 t3.medium at $0.0416/hour costs the same amount at full utilization and at zero utilization. The provider doesn't discount for idle time.
For a typical small SaaS team with 3 developers, a realistic staging footprint might look like:
| Environment | Instance | Monthly cost | Typical utilization | Waste |
|---|---|---|---|---|
| staging-api | t3.medium | $30 | ~8% | $27.60 |
| staging-db | db.t3.micro (RDS) | $15 | ~8% | $13.80 |
| staging-worker | t3.small | $15 | ~5% | $14.25 |
| preview/feature-xyz | t3.small | $15 | ~2% | $14.70 |
| Total | $75/mo | $70.35/mo wasted |
$70 in waste per month is $840 per year. For a small team burning through runway, that's not trivial — but more importantly, it's money that provides zero business value. The instances are running. Nothing is happening on them.
Cloud billing dashboards show total spend by service, by region, by tag — but not by utilization rate. AWS Cost Explorer can show you that an EC2 instance cost $30 last month. It won't tell you that the instance received 12 requests last month.
Most teams don't have utilization monitoring on staging environments. Utilization monitoring is for production — you add CloudWatch metrics, alerts, auto-scaling. For staging, you spin up an instance, point a DNS record at it, and forget about it. It becomes a line item in the cloud bill that nobody questions because it was always there.
The cost is also too small to trigger individual scrutiny. A $30 EC2 instance doesn't get reviewed. The aggregate staging spend ($70-150/month for a typical team) doesn't get optimized because no single instance is obviously wasteful enough to act on.
The idle compute problem is bad for staging. It's significantly worse for preview environments — the per-branch or per-PR environments that modern CD platforms create automatically.
Vercel, Railway, Render, and similar platforms spin up a new environment for every PR. That's the feature: every PR gets its own deployment, with its own URL, for isolated testing. The anti-feature: those environments stay running until the PR is merged or closed — which can be days or weeks.
A team with 5 open PRs at any time has 5 preview environments running continuously, each consuming compute. If the team is active (10 PRs/month), that's potentially 10 × (average PR lifetime) environments running simultaneously. Most are idle within hours of being created.
A common approach: write a script that destroys the staging infrastructure at the end of the day (5pm) and recreates it at the start of the next day (8am). This works in theory and can reduce idle time to ~40%. In practice:
Similar pattern using AWS Lambda or GitHub Actions cron to stop EC2 instances at night and start them in the morning. Better than nothing, but:
Most teams choose this option implicitly. The cost is low enough to not justify the engineering effort to address it. The problem is that "low enough per team" becomes "collectively significant" across thousands of teams.
The better pattern: staging environments hibernate automatically when idle (no requests for N minutes) and wake up automatically when needed (on push, on PR open, on incoming request). The environment is always available; it's just not burning compute when nobody is using it.
This requires:
Some platforms do this natively: Render's free tier suspends services after 15 minutes of inactivity. Railway has a sleep mode. But these are tied to specific platforms, and none provide a cross-platform solution for teams running staging on EC2, ECS, or Kubernetes.
IdleDown detects when your staging environments are idle and hibernates them automatically — across AWS, GCP, Fly.io, and Render. Wake on push, on request, or on schedule. Early access pricing for waitlist members.
Join the IdleDown waitlist → Calculate your staging wasteBest tools to reduce staging costs → · Staging environment cost data → · ← All articles