Audit feature flag cleanup before an outsourced release

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Inventory flags by owner and exposure

Begin with an inventory of every flag that can change the release, not only the ones added in the current sprint. Record the flag key, owner, creation date, current default, and the systems that read it. Include flags managed in the application, the build pipeline, and the deployment platform. A flag without an owner is a control that nobody will retire.

Mark the exposure of each flag: which customers, environments, and code paths it affects. A flag that only changes an internal dashboard has a different risk from one that disables checkout. Record whether the flag can be changed without a deploy and who holds that permission. The inventory should make the blast radius visible before anyone flips a switch. That field drives the cleanup order.

Separate release flags from permanent controls

Not every flag is meant to disappear. A release flag hides unfinished work for a short period, while an operational control may need to stay for incident response. Classify each flag before deciding to remove it. A kill switch that looks old may still be the fastest way to stop a failing dependency. Ask the owner to classify it before cleanup begins.

Write the expected lifetime and the removal condition for each release flag. The condition might be a completed rollout, a stable monitoring window, or a migration that no longer needs a fallback. A flag with no removal condition will survive every review. Permanent controls need a different review cadence and a named operator. A missing condition blocks the flag from release.

Check the off state before the on state

The off state is the path customers will hit if the release goes wrong, so test it first. Disable the flag in a staging copy and confirm that the application still starts, the fallback works, and the logs explain the change. A flag that only works when enabled is not a safe control. Record the result with the same evidence standard as the enabled path.

Check the default in each environment, not only the value in the code. A production default that differs from staging can turn a routine deploy into an outage. Confirm that the flag evaluation fails closed for high-risk behavior. If the fallback is untested, the release is carrying two unknown paths instead of one. Record each environment value in the inventory.

Remove stale flags in small reviewed changes

Remove one flag or one small group at a time. A cleanup pull request that deletes five unrelated flags is hard to review and hard to roll back. Keep the removal separate from the feature change that made the flag obsolete. The reviewer should be able to see which behavior disappears and which test covers it. Link the original rollout note in the cleanup ticket.

Search for every reference before deleting the flag: application code, tests, scripts, dashboards, and runbooks. A removed flag that still appears in an alert can confuse the next responder. Update the flag inventory in the same change. If a reference cannot be removed safely, record the owner and the date for the follow-up. A missed dashboard reference can hide a live signal.

Test the cleanup against the production path

Run the production build and the smoke path after the cleanup, not only the unit tests. Some flag paths are exercised only in a deployed environment because they depend on configuration or a remote evaluator. Compare the behavior before and after with the same test data. A green unit suite does not prove that a removed branch is gone. Use the same smoke test as the release runbook.

Check the logs and metrics for references to the deleted flag. A dashboard that still queries the old key will show a blank panel and hide a real signal. Update the alert thresholds if the removed path carried a fallback. Record the verification time and the person who checked the production path. Remove or update the old query in the same change.

Update the runbook and the rollback note

A flag cleanup changes the rollback plan. If the old path is gone, the team can no longer disable the feature to recover. Update the runbook to name the new recovery action, such as a deploy rollback or a config change. Remove instructions that reference a flag that no longer exists. The new recovery action belongs in the release note.

Give the on-call engineer a short note that explains what changed and how to verify recovery. Link the cleanup pull request and the test evidence. If the change removes a kill switch, require a separate approval from the service owner. The rollback note should be tested, not just edited. Confirm that the note is reachable during an active production incident, including after hours.

Set a review date for every surviving flag

Every flag that survives the audit needs a review date and an owner. Add the date to the inventory and to the team calendar. At the review, ask whether the flag still has a removal condition, whether the default is still correct, and whether anyone has used it in the last quarter. A flag that nobody has changed may be dead weight or an untested control.

Report the number of flags removed, the number reviewed, and the number past their review date. Use the trend to decide whether the team needs a stricter rule for adding flags. Do not reward a low flag count if it comes from deleting controls that incidents still need. The goal is a smaller, owned set of controls that the team can operate.

Frequently asked questions

Sources

1. Martin Fowler, feature toggles

   Taxonomy of release, experiment, permission, and operational toggles.

2. NIST Secure Software Development Framework

   Change and release control expectations.

3. GitHub Docs, about protected branches

   Review and merge controls for cleanup changes.