Config Lifecycle

Feature flags are meant to be removed once the feature has shipped, and configs that nothing reads anymore are clutter that eventually misleads someone. ConfigDirector tracks a lifecycle state for every config from the evaluations your applications report, and tells you when a config has served its purpose.

The state is shown in the Status column of the configs list and on the config page. States are recalculated every 30 minutes.

The lifetime decides the lifecycle

Every config has a lifetime: Temporary or Permanent. The lifetime is the single most important input to the lifecycle, because it tells ConfigDirector whether "this config is no longer needed" is a conclusion it is allowed to draw.

• A temporary config is expected to be removed one day. Feature flags and experiments default to temporary. ConfigDirector tracks temporary configs for cleanup: it detects when they have settled and when they are ready to archive, and raises the two lifecycle alerts.
• A permanent config is expected to stay. Kill switches and plain configs default to permanent. A permanent config that has not been read for a while is not unused, it is waiting, so ConfigDirector never marks it settled or ready to archive, and never suggests removing it.

Both lifetimes share the states that describe plain usage: New, In use, and Stale.

You can change the lifetime at any time from the config's Settings tab. Switching a flag that has become a long-term toggle to permanent takes it out of cleanup tracking; switching a config to temporary puts it in.

States

States transition on their own, and there is no manual reset. A New or Stale config returns to In use as soon as an SDK evaluates it again, and so does an Archive Ready config evaluated in a live environment. An evaluation in another environment brings an Archive Ready config back only when it has no recent real use to judge by, or when an application in that environment is clearly still evaluating it regularly (see Archive Ready). A Settled config returns to In use at the next check once it no longer meets the conditions below.

A permanent config therefore only ever shows New, In use, or Stale. If you expect to see Settled or Archive Ready on a config and never do, check its lifetime first.

How each state is decided

In Use

A config is in use from the moment any environment receives an evaluation for it. Evaluations that fell back to the in-code default value count too: the application is still asking for the config. A temporary config leaves this state when it settles or becomes ready to archive; a permanent config stays in use.

Stale

A config that is more than 15 days old and has never been evaluated is stale, whatever its lifetime. It was created and then never wired into an application, or the application that was going to use it never shipped. The state exists so these configs do not blend in with the ones that are simply new.

Settled (temporary configs)

A settled config is one whose job is done: in your live environments, the feature flag has been on for everyone for a while, or the config has returned the same value to every application for long enough that it might as well live in the code.

The horizon depends on the role:

A temporary config settles when, over the whole horizon and in every live environment that has recent activity:

• Every evaluation served the same value. Evaluations that fell back to the in-code default value are tolerated as long as they are no more than 20% of the total.
• The config was already being evaluated in at least one of those environments when the horizon began, and it is still being evaluated: its latest evaluation is more recent than the config's quiet window (see Archive Ready), or than the horizon when that is shorter.
• The current targeting rules in every one of those environments can only serve that value. A rule or percentage split that could still return a different value to someone, even if nobody matched it during the horizon, means the config is not done yet.
• For feature flags and boolean configs, the value is true. A flag that has been off in every live environment for a week has not shipped, it has been abandoned, and that is a cleanup decision for you rather than a settled verdict.

Only live environments count: those with Live environment turned on in their settings. A staging environment without it that still serves the old value does not hold the config back, and a config in a project without a live environment never settles.

Kill switches are excluded even when they are temporary, because serving the same value for a long time is exactly what a kill switch is supposed to do.

When a config settles, the config page shows the value to hardcode with a copy button, and a Config settled alert is raised.

Archive Ready (temporary configs)

A temporary config that was In use or Settled and then receives no evaluations in its live environments for its quiet window becomes Archive Ready. This is the usual end of a feature flag: the code that read it was removed, the SDKs stopped asking, and the config can go.

The question is whether real traffic still reads the config, so the decision looks at the live environments, the same ones that decide Settled. A developer trying the flag now and then in a test environment neither keeps it in use nor stretches its quiet window. A config with no recent live use at all, because it was never released or its project has no live environment, is judged on whichever environments do evaluate it, so it is not marked ready to archive just for never having gone live. And an application in any environment that still evaluates the config every working day, such as a nightly job in staging, keeps it in use: the code that reads the flag is clearly still there.

Each config has its own quiet window, sized from how often it is usually evaluated in the environments that count, so a config that applications read all day goes quiet within a few days, while one read by a weekly job is given longer. Once a temporary config has been evaluated, hover its status in the configs list to see how long its quiet window is. Dynamic Detection explains how the window is sized and how long it can be. The check runs every 30 minutes, and an Archive Ready config whose evaluations turn out to be more recent than its quiet window, or that an application evaluates every working day, returns to In use.

A Config ready to archive alert is raised when a config enters this state.

A permanent config that stops being evaluated simply stays In use and shows no recent evaluations in the configs list; it is never marked for archival. If you want cleanup tracking for it, change its lifetime to temporary.

What to do in each state

• Settled: hardcode the settled value in your applications, deploy, wait for the state to move to Archive Ready, then archive. If the flag is going to be turned back off again, it is not temporary: change its lifetime to permanent.
• Archive Ready: archive the config from the Settings tab of the config page. The confirmation dialog shows the config's quiet window and when it was last evaluated in each environment.
• Stale: either wire it into the application or archive it.
• In use for a long time with a temporary lifetime: consider whether the flag has become permanent in practice, and if so change its lifetime so it stops being tracked for cleanup.

Archiving

Archiving removes the config from the project and from the SDK payloads. An SDK that still asks for an archived config receives its in-code default value and raises a Config not found alert, which is how you find out if the cleanup ran ahead of a deployment.

Archived configs are listed under View archived configs for 30 days and can be restored from there with their targeting rules intact. After 30 days they are purged.