# Feature Flags Are an Operational Tool

> Separating deploy from release makes frequent deploys safe. Kill switches, load shedding, and flag debt.

Source: https://christwentyfour.com/blog/feature-flags-are-an-operational-tool

Feature flags usually ship as a product tool. Their operational value is bigger. A flag separates deploying code from exposing behavior, and that separation is what makes frequent deploys safe.

## Deploy is not release

Without flags, deploy and release are one event. Every deploy carries user risk, so deploys get rare and large, and each one gets riskier. With flags, code can sit in production for days before anyone sees it. The risky step becomes a config change that reverts in seconds.

## Four operational uses

- **Kill switches** for third-party calls, so you degrade instead of fail.
- **Load shedding** for expensive optional work. Turn off the recommendations panel instead of timing out the page.
- **Manual circuit breaking**, until the automated version exists.
- **Migration cutover**, sending a percentage of reads to the new store while the old one stays authoritative.

## Flags are debt

Each flag doubles the possible states. Give every rollout flag an owner and a removal date when you create it. When the feature is at 100 percent and has been stable for two weeks, remove the flag and the dead branch. Kill switches are permanent, so label them differently.

## Log every change

Record who changed a flag, when, and the previous value. Many outages turn out to be "somebody toggled something."