Why are my feature flags not updating in production?

Feature flags usually stop “updating” in production for one of a few common reasons. The exact fix depends on how you’ve implemented them, but here’s a practical checklist.

1) The app is caching flag values

• Client-side caching: The frontend may fetch flags once on startup and never refresh.
• Server-side caching: Your backend may cache config/flags in memory or Redis with a long TTL.
• CDN/browser cache: If flags are delivered via JSON/config endpoint, it may be cached by HTTP headers.

Check

• Is there a TTL?
• Are requests actually hitting the flag service?
• Do you see stale responses in logs or network traces?

2) The flag service isn’t being polled or subscribed to correctly

Depending on the provider:

• Polling mode: app must periodically fetch updates.
• Streaming/websocket/SSE mode: connection may be broken or blocked.
• Webhook mode: updates may be failing due to auth/network issues.

Check

• Are refresh intervals configured?
• Are streaming connections healthy?
• Any reconnect errors?

3) The production environment has the wrong config

This is very common:

• Wrong environment key/API key
• Pointing prod to staging flag environment
• Missing/incorrect SDK initialization
• Disabled “auto-refresh” in prod only

Check

• Compare prod vs staging config
• Verify environment identifiers and secrets
• Confirm the SDK is initialized exactly once and early enough

4) Flags are evaluated only at startup

Some apps read flags during boot and store them in constants/singletons.

Example issue

• const isNewUI = flagClient.get('new-ui') at startup
• Later updates never affect the running app

Fix

• Re-evaluate flags when rendering/handling requests
• Subscribe to change events if your SDK supports it

5) The deployment process isn’t restarting instances

If flags are loaded into memory at startup and your app only refreshes on restart, long-lived instances keep old values.

Check

• Are old containers/pods still serving traffic?
• Did a rollout actually replace all instances?
• Is there a canary/blue-green setup where only some nodes updated?

6) Sticky sessions or load balancing make it look inconsistent

Some users hit one instance with fresh flags, others hit stale ones.

Check

• Compare behavior across pods/instances
• Inspect session affinity / sticky routing
• Log instance ID with flag evaluations

7) Segment targeting or targeting rules changed, but user context is wrong

The flag may be updating, but the user is not matching the new rule.

Common causes

• Missing user ID / tenant ID / country / plan info
• Anonymous users evaluated differently in prod
• Case mismatches or wrong attribute names

Check

• Log the evaluation context
• Compare it to the targeting rules

8) There’s a kill-switch or override somewhere

Sometimes a local env var, config file, or backend override takes precedence over remote flags.

Check

• Search for “override”, “force”, “default”, or environment-specific config
• Verify precedence order in your implementation

9) The flag provider is delayed or having an incident

If you use LaunchDarkly, Unleash, ConfigCat, Firebase Remote Config, etc., the provider may be degraded.

Check

• Provider status page
• Recent incident alerts
• API error rates/timeouts

---

Fast debugging steps

1. Log the raw flag value at evaluation time in production.
2. Log where it came from: cache, remote fetch, default, override.
3. Check network calls to the flag service from prod.
4. Compare prod/staging config side by side.
5. Force a refresh/restart and see if the flag changes.
6. Verify the user/context attributes used for targeting.

---

If you want, I can help you narrow it down quickly

Reply with:

• which feature flag system you use,
• frontend/backend language,
• whether flags are fetched on startup or dynamically,
• and what “not updating” means (stale for all users vs only some).

I can then give you a more specific diagnosis and fix.