> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/feature-management-experimentation/new-to-fme/get-started/manage-the-feature-flag-lifecycle.md).
# Manage the Feature Flag Lifecycle
As you scale utilization, it becomes increasingly important to have a strategy for how to best clean up feature flags. This should be a consideration from the very first feature flag you create.
When creating new feature flags, there are a variety of reasons for placing a change or new feature behind a feature flag.
### Feature flag types
The three main types of flags to consider are the following:
* **Release Management** feature flags:
* Example: "I want to expose a feature flag to a subset of my traffic that meet a certain criterion (location, age, plan type)"
* Example: "I want to safely do a progressive or gradual rollout for a potentially high impact feature, expose to 10% at first then gradually increase".
* **Experimental** feature flags:
* Example: "I want to learn if the new version of an existing feature, or an entirely new feature, has a positive or negative impact on my business metrics".
* **Operational Control** feature flags:
* Example: "If this feature were to have an issue, it could potentially impact revenue or conversions, I want the ability to quickly revert back to the previous steady-state".
### Retire a feature flag
Now that you have feature flags in production, what are the indicators you might establish for when to retire a flag?
* Feature flags that have not been modified within the past 30 days are eligible for retirement.
* Feature flags that have received no traffic in the last 7 days are eligible for retirement.
* Metrics show that you the feature flag has proven the feature should be rolled out to everyone or removed from code = eligible for retirement.
To surface the feature flags that fall into the first two criteria, within the **Environments** tab in your Split dashboard, you have the option to filter by;
* Active feature flags
* Killed feature flags
* Feature flags that have received traffic in the last 7 days
* Feature flags that have received no traffic in the last 7 days
* Feature flags that have seen no traffic at all
* Feature flags that have been modified in the last 7 days
* Feature flags that have not been modified in the last 30 days
{% hint style="info" %}
**FOR CONSISTENCY**
Before removing a feature flag from code, ensure that everyone in the population is receiving the same intended treatment, essentially rolled out to 100%.
{% endhint %}
### Integrate cleanup tasks into your project process
* As part of the project within the existing Jira ticket (or the feature tracking tool of your choice), you can create a subtask for retiring the feature flag with a specific due date or time period.
* There could also be a subtask within the ticket that states a mandatory feature flag review/kill date.
* Schedule a recurring cadence for the team to review and retire eligible feature flags.
* Adopt a process to add a retire tag on the feature flag once the rollout or experiment is complete.
For an interactive onboarding experience including further use cases and features like \*\*release monitoring\*\*, \*\*events\*\*, and \*\*metrics\*\*, check out the \[\*\*Harness Feature Management & Experimentation Feature Delivery Foundations for Admins & Product Managers certification\*\*]\().