How do you manage feature flags so they reduce risk without becoming long-term code clutter?

In production I define failure behavior before rollout. If the flag provider is slow or unavailable, the application uses a cached last-known value or an explicitly chosen fallback; a remote lookup must not sit on every hot request path without a timeout and cache. A kill switch is rehearsed and may need a different safe state from an ordinary release flag. I separate flag evaluation telemetry from user identity and avoid high-cardinality or sensitive labels while still being able to compare cohorts. Database writes, events, and background jobs need special care because disabling the UI does not undo effects already created, and old and new code may process the same durable state during a rolling release. Cleanup is sequenced: stop creating old-state data, confirm no rollback dependency remains, remove the old code and tests, deploy that change, then delete configuration and dashboards. Automated stale-flag reports use owner and expiry metadata, but removal still receives review. This keeps flags useful for release safety without turning production into a permanent maze of hidden branches.