Feature Flag Lifecycle Review

Audits active feature flags to retire stale flags, confirm ownership, and prevent configuration drift. Ensures flags progress through their full lifecycle from creation through decommissioning.

Review Scope and Identification

• Review date and time
  Record the date and time this lifecycle review is being conducted.
• Reviewer name and role
  Full name and team role of the person conducting this review (e.g., Platform Engineer, Release Manager, Tech Lead).
• System / service under review
  Name of the application, microservice, or platform whose feature flags are being audited.
• Environment scope
  Which environments are included in this review?
• Total number of active flags in scope
  Enter the total count of active feature flags being reviewed in this session.
• Feature flag management platform in use
  Identify the tool or platform used to manage feature flags (e.g., LaunchDarkly, Unleash, Flagsmith, custom in-house system).

Flag Inventory and Ownership Verification

• All active flags have a designated owner (team or individual) documented in the flag management system
  Every flag must have an accountable owner who can make retirement or continuation decisions. Flags without owners are a configuration drift risk.
• Number of flags with no documented owner
  Count of flags currently lacking an assigned owner. Target: 0.
• All flags follow the organization's standard naming convention
  Consistent naming (e.g., [team]_[feature]_[type]) enables searchability and lifecycle tracking. Non-conforming names should be flagged for remediation.
• Each flag has a documented purpose or linked ticket/story
  Flags must be traceable to a business or engineering requirement. Undocumented flags cannot be safely retired or evaluated.
• Each flag has a defined flag type documented
  Flag type should be recorded (e.g., Release Toggle, Experiment/A-B, Ops Toggle, Permission Toggle) to guide lifecycle expectations.
• Owner contact information is current and reachable
  Verify that the listed owner's contact details (email, Slack, team alias) are valid and not pointing to departed employees or disbanded teams.

Staleness and Age Assessment

• Number of flags active for more than 90 days without a scheduled review
  Flags older than 90 days without a review are considered stale candidates. Target: 0. Each should have a documented justification for continued existence.
• All flags older than 90 days have a documented justification for remaining active
  Each long-lived flag must have a written rationale (e.g., permanent ops toggle, ongoing experiment with defined end date) recorded in the flag management system.
• Flags that are 100% enabled or 100% disabled in all environments
  Flags permanently set to a single state in all environments are prime retirement candidates — they are no longer providing toggle value and add dead code risk.
• All flags have a defined expiry date or scheduled review date
  Best practice requires every flag to have a planned review or expiry date set at creation. Flags without expiry dates accumulate as technical debt.
• Flags associated with completed or cancelled features have been identified for retirement
  Features that have been fully released, rolled back permanently, or cancelled should have their flags queued for decommissioning.

Configuration Drift and Risk Evaluation

• Flag configurations are consistent across environments where consistency is required
  Flags that should be in the same state across staging and production (e.g., security controls, compliance features) must be verified for parity. Discrepancies are a non-conformance.
• Number of flags with configuration discrepancies between production and staging
  Count of flags where the enabled/disabled state or targeting rules differ unexpectedly between production and staging. Target: 0 unintentional discrepancies.
• No flags are overriding security controls, authentication, or authorization logic
  Flags that bypass authentication, authorization, or encryption must be reviewed with the security team. Such flags represent a critical risk if left enabled or misconfigured.
• Flags controlling compliance-sensitive features (e.g., data retention, PII handling, audit logging) are reviewed by a compliance stakeholder
  Any flag that can alter data handling, logging, or regulatory compliance behavior must have documented sign-off from a compliance or legal stakeholder.
• Flag targeting rules (user segments, percentage rollouts) are documented and intentional
  Targeting rules should be reviewed to confirm they reflect current intent and have not drifted from the original design due to ad-hoc changes.

Retirement and Decommissioning Actions

• Number of flags approved for retirement during this review
  Total count of flags that have been approved by their owner for decommissioning as a result of this review.
• Each flag approved for retirement has a linked code cleanup ticket
  Retiring a flag from the management platform without removing the associated code branches creates dead code. A ticket must be created and assigned for each flag being retired.
• Retirement timeline established for each flag being decommissioned
  Each flag approved for retirement must have a target decommission date documented, including flag removal from the platform and code cleanup completion.
• Flags being retired have been communicated to all dependent teams
  Teams consuming or depending on the flag behavior must be notified before removal to prevent unexpected breakage.
• Overall flag inventory health rating
  Reviewer's overall assessment of the flag inventory's health based on this review.