When Feature flags go bad
summary
Feature flags enable kill switch rollbacks, gradual canary rollouts and targeted betas but mismanagement causes real damage: a leftover flag nicknamed "powder peg" turns on in production and triggers rapid trades that wipe out about half a billion dollars and takes roughly two hours to contain; an admin-toggle accidentally disables file uploads for three hours. Effective rules are clear, documented names, access control and audit logs, removing flags when done, and using a feature-flag manager like LaunchDarkly instead of scattered config files.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:36Ediths background
- 2:38Release cycles
- 5:10Feature flags
- 6:10Kill switch
- 9:20Controlled rollout
- 10:44Giving early access
- 12:47Blocking early releases
- 13:49Block IP addresses
- 14:46Dark side of feature flags
- 17:09Ambiguously named flags
- 18:44Overuse flags
- 20:08Conflicting flags
- 22:04A real story
- 25:30Left over flags
- 28:37Recipe for effective feature flags
- 31:19Audit log
- 35:06Good feature flags
related talks
56mWhen Feature flags go bad
06mFeature Flag Foul-ups
59mFaster & less risky releases with feature flags
07mKeep Calm and Deploy On: Creating Safer Releases with Feature Flags
30mA Tale of Two Feature Flags
20mFeature Flag-Driven Development… in Reverse
08mThe Art of Feature Flagging
29mSelf-Destructing Feature Flags