No Permanent Overrides
A best practice to prevent feature flag drift.
I originally wrote this guide while working at Square to help my teams address a recurring problem: feature flag overrides applied during incident response were quietly becoming permanent, creating drift between production and staging environments. The advice below is a generalized version of that internal doc, applicable to any team using a feature flag provider.
The Problem
When users report regressions after a new feature rollout, we often respond quickly by removing the affected user from the feature flag rollout or rolling back the flag entirely. While this is the right call for immediate mitigation, the response often creates a long-term maintenance burden: we forget to re-enable the flag or re-enroll the user after the issue is resolved.
These temporary overrides become permanent by accident.
Why This Matters
This leads to fragmented experiences:
Invisible divergence: A user is running a different path than what we see in day-to-day development, making future bugs harder to reproduce or explain.
Rollout inconsistency: Features meant to be universally available instead become fractured across the user base.
Technical debt: Overrides accumulate and become difficult to audit, track, and reason about.
The Cost
Permanent overrides erode our confidence in rollout data and introduce edge cases we didn't plan for. They can also block future rollouts, since we end up tiptoeing around previous exceptions rather than treating the root cause.
In short: they reduce predictability and slow us down.
The Solution: Scheduled Rollback of Overrides
Most modern feature flag providers (LaunchDarkly, Statsig, Flagsmith, Split, etc.) support scheduling the automatic removal of an override. This should be your default approach whenever you respond to a user-facing issue with an override.
Rather than relying on human follow-up or future cleanup work, make the override temporary at the moment it's applied while moving forward to fix the underlying issue.
Example Workflow
Let's say a user hits a bug due to a recent flag rollout:
Override with an expiration. Target the user in your feature flag provider to disable the flag, and schedule the override to be removed automatically, timed to when you expect the fix to ship.
Fix the root cause. Plan and ship the fix through your normal release process.
Because the override already has a time-to-live, the user re-enters the rollout path automatically once the fix is deployed. No manual cleanup or tracking required.
How To Do It
The exact steps vary by provider, but the general pattern is:
Navigate to the flag in your provider's dashboard.
Add the affected user to an individual targeting or exception rule.
When adding the override, look for a "schedule removal" or "add expiration" option. Most providers surface this inline or through a calendar/date picker.
Set the expiration date to align with your expected fix deployment.
Confirm the scheduled change.
If your provider doesn't support scheduled removal natively, create a ticket or calendar reminder at the time of the override. The point is to make cleanup a commitment, not an afterthought.
