> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# The off switch – Feature Flags pocket guide

Canonical URL: https://posthog.com/learn/feature-flags/pocket-guide/off-switch

> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://app.posthog.com` (app host for links).

## On this page

- [A safe default](#a-safe-default)
- [A tested fallback](#a-tested-fallback)
- [A known propagation time](#a-known-propagation-time)
- [Monitoring that tells you to flip it](#monitoring-that-tells-you-to-flip-it)

Chapter 04

# The off switch – Feature Flags pocket guide

To revert a deployment, you need to run a build and a deploy. Your users see the bug while you fight your revert PR through CI/CD. If the change is behind a flag, you switch the flag off in PostHog instead, and each place that checks it stops serving the feature the next time it gets fresh flags.

An off switch you can trust has four parts: a safe default, a tested fallback, a known propagation time, and monitoring that tells you when to flip it.

## A safe default

The off switch works only if the off path still works. Keep the old code working until the flag is gone, and make it the answer whenever the flag isn't a clear `true`:

```javascript
const useNewCheckout = flags.getFlag(NEW_CHECKOUT_FLAG) ?? false

if (!useNewCheckout) return renderCheckout()
return renderNewCheckout()
```

A disabled flag, a flag that hasn't loaded yet, and a check that gets no answer all land on the path that already works.

## A tested fallback

Test that path before you need it. Flip the flag off in staging and confirm the old path works, and have CI run your tests with the flag both on and off.

## A known propagation time

A disabled flag stops matching everywhere it's checked, but each side notices at its own pace. Here's `new-checkout` being switched off:

| Time | What happens |
| --- | --- |
| 14:00 | `new-checkout` raised to 25% |
| 14:11 | Checkout errors triple for people with the flag |
| 14:12 | Flag disabled in PostHog |
| 14:12 | Servers that evaluate remotely: off on the next request |
| By 14:13 | Servers that evaluate locally: off at the next poll, 30 seconds by default |
| Later | Browsers: off at the next flag fetch |

A browser fetches flags on page load, on `identify()`, on a property or group change, and on `reloadFeatureFlags()`, so a tab that stays open can keep the old value for a while. If the feature does damage for as long as one tab holds it, check that flag on the server.

## Monitoring that tells you to flip it

You can only flip the switch as fast as you notice. The 14:11 in the timeline above came from watching, not from a customer email. Put an alert on the signal the change could break, like checkout errors, filtered to people with the flag, so it fires within minutes of the raise. Then send flag changes to Slack, so everyone watching the incident knows who flipped what and when.

Some failures never throw an error, so an alert on errors misses them. The [silent failures scout](https://posthog.com/docs/self-driving/pocket-guide/silent-failure-core-action.md) checks your most important flow every day and matches a drop in completions to the deploy that caused it.

[Open your feature flags](https://app.posthog.com/feature_flags)Find the flag and switch it off.

See also: [Best practices](https://posthog.com/docs/feature-flags/best-practices.md) · [Fallback defaults](https://posthog.com/docs/feature-flags/local-evaluation.md#cold-start-and-fallback-defaults) · [Don't make these feature flag mistakes](https://posthog.com/newsletter/feature-flag-mistakes.md) · [Slack alerts when flags change](https://posthog.com/tutorials/feature-flag-slack-notifications.md)