/Docs
IntroductionHow FeatureGate worksQuickstart
OrganisationsProjectsEnvironments
OverviewTypes and valuesConfigure across environmentsTargeting rulesPercentage rolloutsDesign evaluation contextLifecycle and intentTags and discovery
Choose an evaluation approachEvaluation credentialsNode.js SDKEvaluate over HTTPEvaluate in browsersSnapshots and configuration freshnessErrors and fallbacksTest flags locallyProduction integration checklist
Run a controlled rolloutKill switchesProject insightsActivity and audit historyReview and clean up flagsEnvironment readinessTroubleshooting and limits
Members, roles, and permissionsInvite and manage a teamOrganisation settings and operational defaultsProject lifecycle and transferPlans, billing, and team organisationsOrganisation closure and reactivationAccount settings and security
Management API overviewPreviewProvision flags through automationPreviewRotate runtime keys through automationPreviewAudit project changes through automationPreview
DocsAPI Reference

Operate/Review and clean up flags

Get access
/Docs
Get access
  1. Docs
  2. Operate
  3. Review and clean up flags

Review and clean up flags

Resolve cleanup dates, stale usage, completed rollouts, and archived flag debt.

MarkdownFeedback
PreviousActivity and audit historyNextEnvironment readiness

On this page

Interpret the signalFind every callerResolve globally-on flagsResolve globally-off flagsInvestigate unused signalsResolve long-running partial rolloutsArchive at the right timeVerify completion

Review signals prompt a human decision. FeatureGate never changes a flag automatically because it is old, globally on, globally off, partially rolled out, unused, or archived.

Use review to decide whether to complete, remove, repair, or deliberately retain a runtime decision.

Interpret the signal

SignalLikely question
Cleanup dueHas the temporary flag reached its planned decision point?
Globally on in productionCan code become the new unguarded behaviour?
Off everywhere after trafficWas the work abandoned or intentionally disabled?
UnusedAre hosted callers gone, or is evaluation local?
Review rolloutWhy has production remained partially allocated?
ArchivedHas application code and test cleanup finished?

Signals use effective organisation and project thresholds. They do not inspect source repositories or observe local SDK evaluation.

Find every caller

Search application repositories for the flag key, including:

  • SDK getters and direct HTTP requests.
  • Application wrappers and typed flag maps.
  • Context-building code.
  • Unit, integration, and end-to-end tests.
  • Deployment configuration and bootstrap snapshots.
  • Documentation and incident runbooks.

Search all maintained versions that may still run. A flag absent from the main branch may still be read by an older deployed service.

Resolve globally-on flags

When the new behaviour is intended:

  1. Make it the production environment fallback.
  2. Remove temporary rules and percentage allocation.
  3. Observe the fallback-only state.
  4. Change application code to the new unguarded branch.
  5. Remove obsolete tests and rollout context.
  6. Deploy and verify.
  7. Archive the flag.

Do not jump directly from a 100% rule to archive. Stabilizing the fallback first proves the rule can be removed without changing behaviour.

Resolve globally-off flags

Determine whether the work was abandoned, postponed, or retained as an operational control.

For abandoned temporary work, remove the new branch and the flag. For postponed work, set a realistic review date and record what must change before release resumes.

Do not mark a release flag permanent merely to silence review. Permanent lifecycle means the runtime decision itself is intended to remain.

Investigate unused signals

Hosted usage cannot see local snapshot getters. Confirm application integration before concluding a flag is unused.

Check deployments, source search, bootstrap data, key usage, and application telemetry. If evidence is uncertain, move the review date and document the missing proof.

Resolve long-running partial rollouts

A partial rollout needs a decision: expand, pause with a defined learning goal, roll back, or redesign. Leaving it untouched creates permanent cohort differences and operational ambiguity.

Review the rollout unit, outcome telemetry, customer commitments, exceptions, and rollback condition. Record why the next state is safe.

Archive at the right time

Archive preserves platform history and removes the flag from ordinary active work. It does not remove guarded code or clear snapshots already held by running processes.

Archive after the cleanup deployment reaches required callers. If archive happens earlier, ensure caller defaults preserve the intended state until code removal finishes.

Verify completion

  • Source search finds no production caller.
  • Tests no longer construct the retired flag.
  • Unused context fields and wrappers are removed.
  • The intended behaviour works without FeatureGate.
  • Activity records the cleanup decision.
  • The flag is archived only after caller verification.

Related pages: Flag lifecycle and intent, Run a controlled rollout, and Organisation operational defaults.