Feature flags
Ship code dark, turn it on for a percentage, measure, then ramp or revert.
Feature Flags decouples deploying code from releasing behaviour.
Why it belongs in a monitoring product
A flag flip is a change, and most incidents are caused by a change.
A flag flipped at 14:02 and an error spike at 14:03 is a correlation AccelerUp can make only because both are here. Flag flips appear on the timeline, in the change feed, and in incident correlation.
The pieces
A flag
| Key | The stable identifier your code uses |
| Type | Boolean, string, number, JSON |
| Environments | Per-environment state and rollout |
| Rules | Who sees what |
| Default | What an unmatched subject gets |
The kill switch
The highest-value use, and the one to set up first: a flag around anything risky, so turning it off does not require a deploy.
A kill switch is only a kill switch if flipping it is fast and does not require a build. Test the path — flip it in staging and time how long until a running client sees the change.
Gating AccelerUp's own UI
AccelerUp uses its own flags: FeatureFlagsProvider, useFlag() and the
<Flag> gate. Dogfooding is why the evaluation path is well tested.
Live view
Feature Flags → Live shows evaluations as they happen: which flag, which variant, which subject. It is how you confirm a rule does what you meant before ramping it.
Where this behaviour lives: backend/internal/service/feature_flag_svc.go, frontend/src/app/feature-flags/. If the code and this page disagree, the code is right — please fix the page.
Part of Feature flags — Shipping code dark, then turning it on for a percentage of people.