Setting the file. One moment.
Skill 31 · Launchdarkly Flag Discovery
Subchapter 31.1
references/flag-health-signals.mdMarkdown3 KBView on GitHub
How to interpret the data you get back from LaunchDarkly when assessing flag health.
Every flag in every environment has a lifecycle state. Here’s what each one means and what action it implies:
| State | Meaning | Action |
|---|---|---|
new | Flag was recently created, hasn’t received meaningful traffic | Leave alone: still being set up |
active | Flag is receiving SDK evaluations and serving variations | Healthy, doing its job |
launched | Flag is on, serving a single variation to everyone, no recent changes | Candidate for cleanup: rollout is complete |
inactive | Flag hasn’t received SDK evaluations in a while | Strong candidate for cleanup |
| Signal | How to check | Interpretation |
|---|---|---|
| Last requested date | status.lastRequested on the flag | How recently an SDK evaluated this flag. Older = more stale. |
| Inactive duration | Compare lastRequested to today | 30+ days: likely stale. 7-30 days: might be infrequent. <7 days: probably active. |
| Never requested | lastRequested is null | Flag was created but never evaluated by any SDK. Possibly abandoned during development. |
| Flag age | Compare creationDate to today | Old temporary flags that are inactive are strong cleanup candidates. |
The more complex a flag’s targeting, the more carefully you need to assess it:
| Indicator | What to check | Implications |
|---|---|---|
| Rules count | Number of targeting rules | More rules = more contexts depending on this flag = higher removal risk |
| Individual targets | Users/contexts individually targeted | Someone specifically configured these: check before removing |
| Prerequisites | Other flags that depend on this flag | Hard blocker: cannot remove without updating dependent flags |
| Percentage rollout | Fallthrough uses weighted variations | Flag is mid-rollout: not ready for removal |
Use get-flag-status-across-envs to build a complete picture:
| Pattern | Interpretation |
|---|---|
| Inactive everywhere | Safe to consider for removal |
| Launched everywhere | Rollout complete: candidate for code cleanup |
| Active in production, inactive in staging | Normal: production is the source of truth |
| Inactive in production, active in staging | Unusual: might be pre-release, or staging is stale |
| Mixed states across environments | Needs investigation: don’t recommend action without understanding why |
Combine signals to reach a recommendation:
| Temporary? | State | Age | Dependencies | Recommendation |
|---|---|---|---|---|
| Yes | Inactive 30+ days | Any | None | Strong cleanup candidate |
| Yes | Launched | Any | None | Ready to hardcode and remove |
| Yes | Never requested, 7+ days old | Any | None | Likely abandoned: verify and remove |
| Yes | Active | Any | Any | Leave alone: actively used |
| No | Inactive 30+ days | Any | None | Ask the user: permanent flags may be intentionally dormant |
| No | Launched | Any | None | Ask the user: may want to keep as permanent config |
| Any | Any | Any | Has dependents | Cannot remove: update dependents first |
| Any | Active in some envs | Any | Any | Needs investigation: understand why states differ |