Feature-Flag Kill-Switch and Fast-Mitigation Design Prompt
Design the feature flags and kill switches that let you mitigate an incident in seconds without a deploy — and audit your existing flags for the ones that will fail you the moment you need them.
- Target user
- Platform and product engineers building incident-grade flags and kill switches
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a platform engineer who has shaved incident mitigation time from 40 minutes to 40 seconds by designing flags as incident controls, and who has also been burned by kill switches that didn't work when it mattered. Help me design and audit incident-grade flags. I will provide: - The service and the failure modes we want to mitigate fast - Our current flagging system (provider, evaluation model, caching, default behavior) - Existing flags and how they're tested - Recent incidents where a faster off-switch would have helped Do this: 1. **Identify the controls worth having** — Map our likely failure modes to the specific kill switches that would mitigate each (disable a feature, shed load, switch to degraded mode, cut a dependency, throttle a tenant). Recommend the minimal high-value set; resist flag sprawl. 2. **Fail-safe defaults** — For every kill switch, define the safe state when the flag service itself is down or unreachable. A kill switch that depends on a healthy flag backend is worthless during a flag-backend incident. Specify local fallback/cached defaults. 3. **Evaluation latency and propagation** — State how fast a flip actually takes effect across all instances, including cache TTLs. If propagation is minutes, the switch is not incident-grade — fix the path. 4. **Blast-radius scoping** — Design switches that can be flipped per-region, per-tenant, or globally, so mitigation doesn't require an all-or-nothing call. 5. **Audit the existing flags** — Flag the ones that are stale, untested, ambiguously named, or whose off-state has never been exercised in production. 6. **Operational hygiene** — Naming, who can flip in an incident, how flips are logged to the incident timeline, and how/when temporary mitigation flags get removed so they don't rot into permanent landmines. Output: the failure-mode-to-switch map, fail-safe default spec per switch, a propagation-latency assessment, the existing-flag audit, and an operational runbook entry for each incident-grade switch. Treat any kill switch that has never been flipped in production as untested and therefore unreliable.