When a flag service is unreachable, your code falls back to a default value for every flag. Pick those defaults deliberately. A new, unreleased feature should default to off. A security control should default to on. Treat the fallback as a failure mode you design and test, not an accident.
Why the default matters
Flags are evaluated at runtime and many are fetched from a service. OpenFeature describes a typical system as a stand-alone feature-flagging service plus a client library, and notes that providers can also read a locally stored file. Anything with a network hop can fail.
When it fails, your application still has to decide. The default in your code makes that decision for every flag at once, often during an incident, when nobody is watching closely.
Two kinds of flag, two defaults
Flags that turn a new capability on should fail to off. If the service disappears, users see the old, tested behavior. This is the usual rule for release and experiment flags.
Flags that guard a protective behavior should fail the other way. Examples are rate limiting, extra validation, or a stricter permission path. If the service disappears, you want the protection kept. The risk is a flag whose name reads as enabling something, when its default silently removes a safeguard.
A naming habit helps. Name security flags so that true means protected, and set the code default to true.
Know your provider's behavior
OpenFeature exposes events, including changes in provider readiness and error status. Read your SDK's documentation to learn what it returns when the provider is not ready, whether it caches the last known values, and for how long. Do not guess, because behavior differs between SDKs and providers.
Caching the last known good state is often better than falling back to code defaults, since it keeps production behavior stable through a short outage. Set a maximum age so a stale cache cannot persist for days.
Test the failure on purpose
Add a test or game day step that cuts off the flag service. Then check three things.
- The application starts, or fails with a clear message rather than hanging.
- Every flag resolves to the value you intended.
- An alert fires, so someone learns the service is down.
Run the same check after a major flag SDK upgrade.
Startup versus runtime
A service that cannot reach its flag provider at startup is a different case from one that loses it later. Decide whether startup should block until flags load, which is safer for security flags, or proceed with defaults, which favors availability. Write the choice down per service.
A small example
A team has two flags. new-search-ranking is a release flag, so its default is false. If the service is down, users get the old ranking. require-mfa-for-export is a protective flag, so its default is true. If the service is down, exports still demand a second factor. The team confirmed both by blocking the flag service in staging and running the export test.
One more habit
Keep a short table in the repository of each flag, its default, and the reason. During a review, anyone can see that a flag's default matches its purpose. Remove entries when flags are removed, which ties into flag expiry dates.
Quick check
What should a new feature flag default to?
Off. If the flag service fails, users keep the old, tested behavior.
What should a flag that protects something default to?
On, meaning protected. Name it so that true means protected, and test the outage case.
Sources
Last reviewed: 19 October 2026.
