Start Free
Guide

Kill Switches

Turn a flag off and every evaluation starts returning the default value within seconds, no deploy, no rollback, no incident war room.

How it works

Each flag has an enabled switch, separate from its rules. When it is off, evaluation short-circuits before any rule runs: every call returns the flag's default value with reason: 'flag_disabled'. Flip it back on and your rules and rollouts resume exactly where they were, nothing is lost.

The kill switch serves the flag's default, not the default in your code. Those are two different values. The argument you pass to evaluate() is only used when the SDK can't get an answer at all. Check that the flag's configured default is the safe value before you rely on the switch in an incident.

Propagation

  • Streaming SDKs: receive the change over SSE within seconds.
  • Polling SDKs: pick it up on the next refresh interval, 30s by default.
  • Direct REST: every call re-evaluates, so the change applies as soon as the edge cache is invalidated.
  • Edge SDK: applies on the next blob refresh, either the push signal or the polling interval.

Patterns

Three habits that make kill switches actually save you:

  1. Wrap risky launches. Every new feature ships behind a flag for at least a week. The kill switch is your one-click rollback.
  2. Wrap external dependencies. Put a flag around any third party, payments, analytics, AI, so you can shed load when they go down.
  3. Pick safe defaults. The flag's default is what users see when it is off. Make sure that path still works without the new code, and keep it exercised in tests so it doesn't rot.

Rehearse it

A kill switch you have never pulled is a hypothesis. Verify the disabled path in staging, and confirm the reason is what you expect:

terminal 
curl -X POST https://api.shipsilently.com/v1/evaluate \
  -H "X-API-Key: $SHIPSILENTLY_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "flagKey": "risky-feature", "context": { "userId": "u_123" } }'

# { "flagKey": "risky-feature", "value": false, "reason": "flag_disabled" }
Don't use a kill switch as a permanent feature toggle. Delete the flag once a feature is fully launched, stale flags become technical debt.

Audit trail

Every toggle is recorded as a flag.toggled audit event with the actor, the timestamp, and a before/after diff of what changed. You can review the full history of any flag from its detail page, which is usually the fastest way to answer "when did this change and who did it" during an incident.