Kill switches

A kill switch is an environment-specific emergency override. While active, its typed emergency value wins before targeting rules and the normal fallback.

The underlying rules and fallback remain stored for restoration. Use a kill switch for a prepared operational control, not as a substitute for ordinary rollout management.

Choose appropriate controls

Good kill switches have a clear emergency meaning, a safe value, and an owner who can validate the result. Examples include disabling a risky integration or returning to a simpler processing path.

Avoid using a kill switch when:

• A normal targeting rule can reverse the release safely.
• The value would bypass authorization or data validation.
• No operator knows how to validate the emergency state.
• The underlying application cannot tolerate configuration staleness.

Operational intent and permanent lifecycle are often appropriate, but the flag still needs periodic review and rehearsal.

Prepare before an incident

For every operational flag:

1. Choose the emergency value for each relevant environment.
2. Document affected services and expected behaviour.
3. Define who may trigger and who owns incident validation.
4. Confirm application defaults and snapshot freshness expectations.
5. Test the override in non-production.
6. Verify eligible builders receive kill-switch notifications.

Members, admins, and owners can build inside projects and trigger the control. Viewers cannot change flags. Organisation roles do not grant access to FeatureGate's private operator portal.

Trigger the override

Open the flag detail, select the affected environment, and choose Trigger kill switch. Review the typed value and add a concise incident reason.

The override affects only the selected environment. Repeat the action deliberately when an incident requires more than one environment.

Triggering records organisation activity and sends the configured kill-switch notification to eligible builders whose account preferences permit it.

Validate the incident state

Use a hosted evaluation or the application's own observability to verify behaviour. Confirm the response environment and evaluation reason rather than assuming the console save reached every caller.

Snapshot clients see the override after a successful refresh. A running process may briefly retain the previous snapshot, or retain it longer during a refresh outage.

If immediate propagation is essential, use application operational controls alongside FeatureGate. Do not promise stronger consistency than the chosen evaluation approach provides.

Restore normal configuration

Restore only after the incident owner confirms the preserved fallback and rules are still correct. Restoration reactivates them; it does not rebuild configuration from scratch.

After restoration:

1. Verify hosted and application behaviour again.
2. Confirm snapshot clients refreshed successfully.
3. Record the incident outcome in activity notes.
4. Decide whether rules, defaults, or code need a permanent change.
5. Schedule a rehearsal or follow-up if validation was unclear.

Restoration is recorded in activity but does not send the same kill-switch broadcast. Coordinate the recovery through the incident process.

Failure cases

• The application did not change: inspect snapshot refresh health and environment binding.
• Only one runtime changed: confirm every affected environment was selected deliberately.
• The emergency value is unsafe: restore or choose a corrected typed value and update the runbook.
• Notifications did not arrive: review account preferences and eligible recipient policy.
• Underlying rules are obsolete: repair normal configuration before restoration.

Never include secrets, raw customer identifiers, targeting values, or incident payloads in reasons or activity notes.

Related pages: Flag lifecycle and intent, Snapshots and freshness, and Activity and audit history.