# Managing Feature Gate lifecycles > For AI agents: a documentation index is available at [/llms.txt](/llms.txt). Append `.md` to any page URL for markdown, or send `Accept: text/markdown`. A feature can go through different phases throughout its lifecycle. A few users may test it, you may have recently rolled it out to everyone, or it may be stable enough that you no longer need the toggle. A feature gate should clearly reflect the phase the feature is in, for a few important reasons: - **Prevent incidents**: Avoid scenarios where old code for a deprecated feature is accidentally touched or repurposed. These incidents have had real business consequences, as in [how Knight Capital lost half a billion dollars](https://www.statsig.com/blog/lose-half-a-billion-dollars-with-bad-feature-flags-knight-capital). - **Maintain a healthy codebase**: Dead references to flags increase the volume of code your team navigates daily and can slow down new developer onboarding. - **Reduce mental load**: The feature gate catalog shows the status of every feature, so you can quickly see what next steps are needed (for example, launch or end a feature) without tracking everything manually. ## Managing feature gate lifecycles Statsig makes it easy for your feature gates to reflect the phase your feature is in by using **status**. A gate can be in one of four statuses: ![Feature gate status options interface](https://docs.statsig.com/images/feature-flags/feature-flags-lifecycle/216169028-44ca6ce1-1300-44b6-9156-55ea52cd85ea.png) | Status | What it represents | Implication | | --- | --- | --- | | In Progress | You're rolling out and testing this feature. | Default status when you create a gate. | | Launched | You've rolled out this feature to everyone. | The gate always returns **TRUE** and stops generating billable exposure events, so you stop incurring costs. The gate reference is likely safe to clean up from the codebase. | | Disabled | You've rolled back this feature from everyone. | The gate always returns **FALSE** and stops generating billable exposure events, so you stop incurring costs. The gate reference is likely safe to clean up from the codebase. | | Archived | Your code no longer references or checks this feature; Statsig preserves the gate's history. | The gate has received 0 checks for the last 7 days and receives no more checks. | ## When to update feature gate lifecycles There are 3 points throughout the gate's lifecycle when you should take action, either in the console or in your codebase: ![Feature gate lifecycle workflow diagram](https://docs.statsig.com/images/feature-flags/feature-flags-lifecycle/216169769-23062719-92da-4ae5-a437-935b2ef5b05c.png) **1) You've fully rolled out or rolled back the gate, and you're ready to skip rule evaluation and assign a default value** - Go to the feature gate page and click the "..." menu in the upper right corner to select **Launch** or **Disable**: - **In Progress → Launch**: when you've rolled out the gate to 100% for a period of time (recommended: more than 30 days) and you're comfortable with the gate always returning TRUE. - **In Progress → Disable**: when you've rolled back the gate to 0% for a period of time (recommended: more than 30 days) and you're comfortable with the gate always returning FALSE. - To find all gates that are good candidates to be **Launched** or **Disabled** (rolled out to 100% or rolled back to 0% more than 30 days ago): - Go to Feature Gates catalog - Click on filter icon: - Status = In Progress - Pass Rate = 100% AND 0% - In the search bar: "Modified: ` **Note:** > > Confirm that no active Holdouts include these gates before removing reference. - To find all gates that are good candidates to remove from your codebase (Launched or Disabled more than 60 days ago): - Go to Feature Gates catalog - Click on filter icon: Status = **Launched** AND **Disabled** - In search bar: "Modified: `