FeatureGate

Flag lifecycle

Classify flags, set cleanup review dates, and keep release toggles from becoming permanent clutter.

Feature flags are easiest to operate when every flag has an owner, a purpose, and an expected end state. FeatureGate treats newly created flags as temporary release flags by default, then asks for a cleanup review when the flag has reached its review date or starts behaving like finished rollout work.

Lifecycle type

  • Temporary flags are release, experiment, migration, or short-lived maintenance controls. They should have a cleanup review date and a note that says what should happen after rollout.
  • Permanent flags are long-lived operational, entitlement, permission, or configuration controls. They stay visible, but long-running rollout signals do not ask you to remove them.

Use permanent flags sparingly. If a flag is really product configuration, name it like configuration and keep its defaults and targeting easy to audit.

Intent

Choose the closest intent when creating or editing a flag:

  • Release: ship a feature gradually, then remove the branch.
  • Experiment: compare behavior for a measured period.
  • Ops: keep an operational escape hatch or traffic control.
  • Permission: gate access by plan, account, workspace, or user.
  • Configuration: tune runtime behavior without redeploying.
  • Maintenance: coordinate migrations or temporary platform work.

Intent helps reviewers understand why a flag exists before they inspect rules or code.

Cleanup review

Temporary flags have a cleanup review date. When that date passes, the flag moves into the console review filter as Cleanup due.

FeatureGate also raises review signals for mature temporary flags that are globally on in production, off everywhere after real traffic, unused past the stale threshold, or running production targeting for a long time. Permanent flags still show traffic and activity, but those release-cleanup signals are suppressed.

Use cleanup branches

When a release flag is shipped everywhere, make a small cleanup branch like cleanup/new-checkout. Remove the guarded code path, archive the flag in FeatureGate, and keep the branch easy to review.

Change notes

Targeting rule edits can include an optional change note. Use it for the reason a rollout moved, the support case behind a rule, or the expected rollback condition. Notes are stored with activity events, not runtime evaluation data.

Next steps