Definition
Feature Flag
A feature flag (or feature toggle) is a runtime switch that turns a piece of functionality on or off without deploying new code. It decouples deployment from release, letting teams ship code dark, roll a feature out gradually, target specific users, run experiments, and instantly disable a problem — all through configuration rather than a redeploy.
Key takeaways
- A feature flag is a runtime switch that enables or disables functionality without deploying new code.
- It decouples deployment from release — code can be live in production yet hidden until the flag flips.
- Flags enable gradual rollouts, user targeting, experiments, and an instant kill switch that's safer than an emergency rollback.
- Flag hygiene matters: stale flags are dead conditional logic, so treat them as temporary with an owner and removal date.
A feature flag wraps new code in a conditional whose value is read at runtime from configuration. Because the switch is data, not code, behavior can change without shipping a new build. This breaks the rigid coupling between deploying code and releasing a feature: the code can be live in production yet invisible until the flag flips.
That separation unlocks several patterns. Teams ship work to production continuously while it's still hidden, avoiding long-lived branches. They roll features out to 1%, then 10%, then everyone, watching metrics at each step. They target flags by user, plan, or region. And critically, they get a kill switch — when something breaks, flipping a flag is faster and safer than an emergency rollback.
The discipline is hygiene. Flags accumulate; a stale flag is dead conditional logic that confuses readers and multiplies test paths. Mature teams treat flags as temporary by default, tracking each one's owner and removal date, and distinguish short-lived release flags from long-lived operational or permission toggles.
Planoda integrates with flag systems via signed webhooks, so a flag flip can open a tracked rollout issue or trigger a canary check, keeping release state and work in sync.
Related terms
- Canary ReleaseA canary release is a deployment strategy that rolls new code out to a small subset of users or servers first, monitors it closely for errors or regressions, and only proceeds to a full rollout if it stays healthy. Named after the canary in a coal mine, it limits the blast radius of a bad change and enables fast, low-risk rollback.
- CI/CD (Continuous Integration / Continuous Delivery)CI/CD is the practice of automatically building, testing, and releasing code through a pipeline triggered by every change. Continuous integration merges and verifies work frequently to catch conflicts early; continuous delivery keeps the software always in a releasable state, often deploying automatically. Together they shorten the path from a commit to running in production.
- WebhookA webhook is an automated HTTP request a system sends to a URL you provide whenever a specified event occurs — an issue created, a status changed, a comment added. Instead of repeatedly polling an API for changes, your service receives a real-time push. Webhooks are the backbone of integrations, letting tools react to each other instantly.
- Technical DebtTechnical debt is the implied future cost of choosing an easier or faster solution now over a better one that takes longer. Like financial debt, it accrues interest: shortcuts in code, architecture, or tests slow every future change until they're repaid through refactoring. Some debt is deliberate and strategic; some is accidental and corrosive.
- Service-Level Objective (SLO)A service-level objective (SLO) is a measurable target for a system's reliability over a window — for example, 99.9% of requests succeeding in 30 days. It is set against a service-level indicator (a metric like success rate or latency) and is the internal goal that informs the externally promised SLA, giving teams a precise definition of "reliable enough."