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

A config in any of these states returns to In Use as soon as an SDK evaluates it again. There is nothing to reset.

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 when any environment has received an evaluation for it in the last 7 days. Evaluations that fell back to the in-code default value count too: the application is still asking for the config.

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. 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 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 under 20% of the total.
• Every one of those environments has evaluations across the full horizon, including the last day.
• 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 everywhere for a week has not shipped, it has been abandoned, and that is a cleanup decision for you rather than a settled verdict.

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 any environment for 7 days 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.

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 until the 7 days pass and then shows no 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: convert it to a kill switch, or change its lifetime to permanent.
• Archive Ready: archive the config from the Settings tab of the config page. The confirmation dialog shows 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.