We've all been there: CI is green, all tests are passing, we say "deploy"… and 20 minutes later the alert goes off. The first reaction is "were the tests not good enough?" But usually the problem isn't the tests — it's the unseen differences between the test environment and production.

Here are the four silent differences I run into the most:

1. Config differences — This is usually the biggest culprit. Connection strings, feature flags, API keys, timeout values… A single difference between appsettings.Development.json and the environment variables in production can change the behavior. If your tests don't run in the "right environment", a green result doesn't mean much.
2. Data differences — The test database has 20 clean records; production has 2 million — some null, some ten years old, some in formats you never expected. A query that returns instantly in tests can take 15 seconds in production. If your data doesn't look like production, you'll never catch performance issues or edge cases.
3. Timeout and timing differences — Locally everything responds in milliseconds; in production a third-party API might take 2 seconds, and a busy database 30. Timeouts that never trigger in tests will knock on your door within the first week of going live.
4. Scale and concurrency — Everything works with a single user. But when 50 concurrent requests try to update the same row, everything changes. If you haven't written concurrency scenarios, you'll hear "but the tests passed" a lot from your colleagues.

So what should we do?

• Deliberately make the test environment resemble production: same config, similar data volume, realistic hardware.
• Instead of small, clean datasets, use anonymized samples from production.
• Don't zero out timeouts; work with realistic timings in tests too.
• Add concurrency tests to critical flows and set up basic monitoring, so production differences don't go unnoticed.

Green tests give you confidence — but that confidence is only as real as how closely your test environment mirrors production.