Feature flags pile up like technical debt until they become a deployment liability—and nobody owns the cleanup.
Feature flags are scaffolding, not permanent infrastructure. But they behave like permanent infrastructure because nobody schedules their removal. Six months after an experiment ends, the conditional logic is still in your codebase. A year later, you have 200+ flags and nobody remembers which ones actually control live traffic. This workflow solves that by making flag cleanup a scheduled, accountable process instead of a post-mortem task. How it works: On a weekly cadence (or your chosen interval), the system queries your feature flag platform—LaunchDarkly, Unleash, or your custom store—and identifies candidates for removal: flags with zero traffic in 30+ days, flags in rollout states that shipped weeks ago, flags with no recent targeting rule changes. For each candidate, it pulls the flag owner from your config (or defaults to the last engineer who touched it) and sends a structured notification: flag name, last traffic date, current state, and a removal readiness form. The owner responds with one of three signals: "Remove this," "Keep it, here's why," or "Needs investigation." Flags marked for removal enter a 7-day hold period—visible in Slack or your ops dashboard—before automated deletion. If an owner doesn't respond in 5 days, a reminder goes out. If they still don't respond after 10 days, the flag escalates to the engineering lead for triage. This creates three layers of safety: (1) the owner has first-mover advantage to protect flags they know are still needed, (2) the hold period catches any last-minute dependencies, and (3) the escalation prevents flags from languishing in limbo. The workflow also tracks metrics: flags removed per week, average time-to-removal, flags that were kept and why, and flags that triggered incidents after removal (the real failure signal). Over time, you'll see which teams are good at flag hygiene and which ones accumulate debt.
Trigger: Weekly schedule (e.g., Monday 9 AM UTC). Can also be triggered manually when a deployment risk review surfaces too many active flags.
Connect to your flag management platform (LaunchDarkly API, Unleash, or custom endpoint) and retrieve all flags matching cleanup criteria: age > threshold, status = shipped/rolled out, no recent changes, not in exclusion list. Export results with flag name, owner, creation date, last modified date, current rollout %, and linked experiment/ticket.
Cross-reference flag candidates against code repositories and deployment logs to identify where each flag is referenced. Detect conditional logic, feature branches, and downstream dependencies. Flag any that appear in critical paths or multiple services. Attach this context to each candidate record for owner review.
Send templated Slack, email, or in-app notifications to flag owners listing their assigned flags for review. Include: flag name, age, rollout status, usage context, and a link to a shared document or form. Set a response deadline (e.g., 5 business days). Provide a checklist: confirm flag is safe to remove, document any dependencies, confirm no active experiments, sign off on removal.
Use a shared form (Google Form, Airtable, Jira, or custom tool) to collect owner responses. Fields: flag name, owner name, removal readiness (yes/no/needs investigation), blockers or dependencies, linked ticket for removal, and sign-off timestamp. Automate reminders for non-responders at day 3 and day 5.
Review responses and flag any entries marked 'needs investigation' or with documented blockers. Create tickets or Slack threads to resolve dependencies (e.g., code still referencing the flag, active A/B test, customer-specific rollout). Assign to engineering or product lead. Do not proceed with removal until blocker is cleared.
Compile all flags approved for removal into a prioritized backlog. Sort by: flags with zero dependencies (lowest risk), flags in single service (medium risk), flags in multiple services (highest risk). Create Jira/GitHub tickets for each removal with: flag name, owner, removal steps, code locations, and rollback plan. Link to original owner sign-off.
Assign cleanup tickets to engineering sprints over the next 1–2 quarters. Batch removals by service or codebase to reduce review overhead. Ensure each removal includes: code cleanup, test updates, documentation, and flag deletion from management system. Pair with low-risk releases or maintenance windows.
Monitor Jira/GitHub for merged removal PRs. Update a shared dashboard with: flags removed this cycle, total flags remaining, average flag age, and removal velocity. Report monthly to product leadership. Use metrics to forecast next cleanup cycle and adjust cadence if needed.
1. Connect your feature flag platform (API key for LaunchDarkly, Unleash, or custom endpoint). 2. Define stale criteria: zero traffic in 30+ days, or in 'rollout complete' state for 14+ days, or created >90 days ago with zero rule changes. 3. Map flag owners: pull from flag metadata, or default to git blame on the file containing the flag definition. 4. Set up notification template in Slack or email with flag name, last traffic timestamp, current state, and a link to the removal readiness form (Google Form, Typeform, or custom). 5. Create a 7-day hold list in a shared doc or Airtable. 6. Configure escalation: if no response in 10 days, notify the engineering lead with a list of unresponded flags. 7. Set up automated deletion: after 7-day hold + owner approval, flag is removed from the platform and a PR is auto-generated to remove the code conditional.