Killswitches
A flag with a single job — disable a system instantly during an incident.
A killswitch is a boolean flag with one purpose: be the lever you pull when something is on fire. It looks like a feature flag but lives in its own list, has no rollout percentage, and defaults to the safe position so on-call doesn't have to think.
Why a separate primitive?
Feature flags have targeting rules, ramps, and dozens of them per project. Killswitches have one switch and
a name. Mixing them is dangerous — at 3am you do not want to fat-finger a --rollout 100 instead of
--off.
If a junior on-call engineer needs to flip this in five seconds without reading the docs, it's a killswitch. Not a feature flag.
Anatomy
switch — the only state→
Boolean. on means the system runs. off means it's killed. There is no rollout percentage by
design.
default — fail-safe→
What gate('killswitch-name') returns if the SDK can't reach our service. Default true
(system runs) for most cases; false for new features still being qualified.
audit — who flipped what→
Every flip is recorded with actor + timestamp in the activity log. Linkable in your incident timeline.
alerting — page someone→
Wire the killswitch.flipped webhook to your alerting so the team knows when production is in
degraded mode.
Lifecycle
- Create.
shipeasy killswitch create transactional.email-sender --description "Disables outbound email" --value false(killswitch names must befolder.name;--value falsemeans "not killed by default"). - Wire it in. Wrap the call in your code:
if (!(await gate("email-sender"))) return; // killed await sendEmail(payload); - Page-time. Flip it instantly:
shipeasy killswitch update transactional.email-sender --value true - Recover. Once the incident is closed, flip it back and post-mortem the audit log.
Killswitch vs feature flag vs config
| Question | Killswitch | Feature flag | Config |
|---|---|---|---|
| Output | boolean | boolean | typed value (string/number/json/bool) |
| Targeting rules? | no | yes | yes (per-env) |
| Rollout percentage? | no | yes | n/a |
| Default if unreachable? | configurable, usually true | false | last-known-good |
| Use case | break-glass during incident | progressive rollout | non-boolean values |
See also
- Feature flags — the everyday rollout primitive
- Decision tree — pick the right primitive for the change you're shipping
- API reference —
POST /api/admin/killswitchesetc. - CLI —
shipeasy killswitch …commands