A feature works in staging. It ships. It breaks in production, in a way nobody can reproduce locally, and the on-call engineer spends an hour before finding the actual difference: a feature flag is on in staging and off in production, and nobody remembers deciding that, because nobody did. It drifted there, one config change at a time, over months.
This is configuration drift, and it is a specific, quiet failure mode that has nothing to do with the code being wrong. The code is identical across every environment. The environments are not.
Why this is not a code review problem
Code review catches mistakes in what you are about to ship. It does not catch a mismatch between what a flag is set to in staging versus production, because that setting usually is not in the code at all. It lives in a database row, a config management console, an environment variable set by hand three deploys ago, or a feature-flag platform's dashboard, none of which a pull request touches.
A change that only exists as configuration state, rather than as a line in a diff, has no review step by default. Someone flips a flag to debug something, forgets to flip it back, and that forgotten flip is now a permanent, undocumented difference between two environments that everyone assumes are the same.
Where the assumption of parity actually breaks
Feature flags left on in one environment for testing and never turned off, particularly flags added for a specific investigation, a load test, or a one-off diagnostic, that outlive the reason they were created because turning a flag off is a task nobody owns once the immediate need passes.
Environment variables set manually during an incident and never reverted. A timeout value raised temporarily to work around a slow dependency, a retry count changed to reduce load, a rate limit relaxed to let a backlog clear. Each change was correct and necessary at the time. None of them were ever tracked as temporary, so none of them were ever undone.
Database-backed configuration that diverges because it is edited directly, through an admin panel or a database console, rather than through a change that is versioned and applied consistently across environments. A row edited in production to fix an urgent problem has no corresponding edit in staging, and the two environments now genuinely differ in a way no diff will ever show.
Third-party service configuration, a webhook URL, a rate limit tier, a plan setting, that was changed in one account and not the other, usually during initial setup or an early debugging session, and then never revisited because nobody thought of it as configuration that could drift the same way application config does.
Why staging existing does not solve this
The entire point of a staging environment is to test changes before they reach production, and that only works if staging and production actually resemble each other. Configuration drift undermines this specifically: a change tests cleanly in staging not because it is safe, but because staging happens to be missing the exact condition that would have caused a problem, or has an extra one that happens to mask it.
This produces a particularly frustrating failure pattern: the same code, tested and verified in an environment that is supposed to be representative, behaves differently in production for reasons that have nothing to do with the deploy itself. Debugging it starts from the code, because that is what changed, and the actual cause is something that did not change at all, a setting that has been different for months.
What actually prevents this
Treat configuration as code, wherever that is genuinely possible. Feature flags, environment variables, and service settings that are defined in version-controlled files, applied through the same deploy pipeline as application code, are reviewed the same way a code change is reviewed, and a diff between environments becomes something you can actually look at rather than something you have to reconstruct from memory.
For configuration that cannot live in version control, database-backed flags, third-party dashboards, build a periodic diff instead. A scheduled job that pulls the current configuration state from every environment and reports differences is far cheaper to build than it sounds, and it converts an invisible, slowly accumulating drift into a list someone actually sees and can act on.
Give every temporary configuration change an expiry, not just an intention to revert it later. A flag flipped for an investigation, a timeout raised during an incident, should come with a specific date it gets reviewed and either made permanent, deliberately, or reverted. Without that date, "temporary" configuration changes accumulate indefinitely, because nothing forces the review that would catch them.
When debugging a production-only issue, check configuration parity before re-reading the code. If the code is identical across environments and the behavior is not, the fastest path to the actual cause is usually a direct comparison of flags, environment variables, and settings between the two environments, not another pass through logic that has already been reviewed and tested.
Check yours
Pick one environment pair, staging and production, or two regional deployments of the same service, and generate an actual diff of every feature flag, environment variable, and configuration setting between them. Do this by comparing real current state, not by asking whether anyone remembers a difference. The list that comes back is very likely longer, and stranger, than anyone expects, and at least one entry on it is a forgotten debugging change from months ago that nobody ever reverted.
The concession
Perfect configuration parity across every environment is not actually the goal, and treating any difference as a bug misses that staging legitimately needs different values for some things: smaller resource limits, different third-party sandbox credentials, more verbose logging. Some drift is intentional and correct.
The distinction that matters is between drift that is deliberate and documented, and drift that accumulated silently because nobody was watching for it. A staging environment with a smaller connection pool by design is fine. A production feature flag left on since an investigation four months ago, that nobody remembers setting, is not the same kind of difference, even though both would show up on the same diff.
The implication
Two environments running identical code are not the same environment, and the assumption that they are is exactly what makes a configuration-driven bug so disorienting to debug: everyone starts by re-checking the code, because the code is the thing that is supposed to differ when behavior differs, and in this specific failure mode, it is the one thing that did not.
Run the diff before you need it for an incident. The value of knowing your environments have drifted is highest before that drift causes an outage, and lowest, though still real, after you have already spent an hour tracing a production-only bug back to a setting nobody remembers changing.
