# Staging Lies to You

> Staging answers a weaker question than the one you ask. What it is good for.

Source: https://christwentyfour.com/blog/staging-lies-to-you

Every team has a staging environment. Every team has had incidents it missed. The problem is what you expect from it.

Staging differs from production in ways nobody wrote down. Less data. Fewer instances. A smaller database with a different query plan. No real traffic. Each difference is reasonable. Together they mean staging answers a weaker question. "It works in staging" really means "nothing obviously broken."

## What staging catches

It is good at breakage that shows up everywhere: a bad migration, a missing variable, a service that will not start, a broken contract. It is poor at scale, real data shapes, concurrency, and three years of accumulated state. That is most of the interesting failures.

## Don't chase identical

Copy the free parts: the same deploy mechanism, config shape, and container image. Full parity costs too much and never arrives. The closer you get, the more you trust it, which is its own risk.

## Get faster at finding out in production

Deploy without releasing. Send a small share of traffic first. Watch the right signals for a few minutes. Reverse fast if the answer is bad.

## Give staging an honest job

Treat a pass as "no known problems," not "safe." Put the same instrumentation in both. Test the rollback path hardest, because you will rely on it when staging was wrong.