Configuration and feature flags release incidents

Configuration and feature flags: 5 published incident types backed by 13 public reports.

The root-cause stage named most often in this group is config, in 5 of 5 incident types.

5 incident types published · 3 withheld · 13 public reports

Incident types in this group

Configuration and feature flags


Config change without restart semantics	Likelihood: low (2 public reports in 5 years)	Impact: medium (2 of 2 reports: availability)	2
Environment mismatch: production points to staging	Likelihood: low (2 public reports in 5 years)	Impact: unrated (fewer than 2 reports state impact)	2
Flag default flips on missing config	Likelihood: low (2 public reports in 5 years)	Impact: low (2 of 2 reports: degraded)	2
Flag enabled for wrong segment	Likelihood: low (2 public reports in 5 years)	Impact: medium (1 of 2 reports: availability)	3
Rate limit misconfigured	Likelihood: medium (4 public reports in 5 years)	Impact: medium (4 of 4 reports: availability)	4

Withheld in this group: Secret in logs after logging change, Stale flag removed with live traffic, Kill switch does not disable feature. Reasons per route

Risk grid

Risk grid: count of incident types per likelihood and impact cell, from data/risk.json
Likelihood \ Impact	Impact: high	Impact: medium	Impact: low
Likelihood: high	0	0	0
Likelihood: medium	0	1	0
Likelihood: low	0	2	1
Impact unrated or likelihood not graded	1

Table equivalent: incidents per cell

Incident	Likelihood	Impact
Config change without restart semantics	low	medium
Environment mismatch: production points to staging	low	unrated
Flag default flips on missing config	low	low
Flag enabled for wrong segment	low	medium
Rate limit misconfigured	medium	medium

Root-cause stages

Stage	Incident types naming it
config	5
release-process	2
code	1
third-party	1

Median time to detection across the group: 136.5 minutes from 2 reports that state both the change time and the detection time (values above the site-wide 95th percentile excluded).

Only on this page

Every published incident type in this group names the config stage among its root causes.

Group checklist

The first pre-release item of each published incident type in the group.

GR-01Config change without restart semantics: After a secret rotation, list the secret version each component process holds and confirm none still uses the old version. config
GR-02Environment mismatch: production points to staging: Before promotion, confirm that every release in the list returned by the progressive deployment API belongs to the production account. config
GR-03Flag default flips on missing config: Compare the flag set of every region with the release's flag list and fail the release when a region such as the EU lacks a flag the update depends on. config
GR-04Flag enabled for wrong segment: List the audience every changed flag rule resolves to and confirm internal-test flags resolve only to internal accounts, not to every first-party application. config
GR-05Rate limit misconfigured: Diff the rate limit values of each public API between the release and production and block the change when any limit drops without an approved change record. config

Questions

What causes Configuration and feature flags incidents?

Published incident types in this group name these root-cause stages: config (5), release-process (2), code (1), third-party (1).

Which pipeline stage introduces most Configuration and feature flags incidents?

The config stage, named in 5 of 5 published incident types in the group.

Which test classes catch Configuration and feature flags incidents?

Test classes listed on the group's incident pages: configuration and environment tests (5), canary and progressive delivery checks (5), chaos and resilience tests (2), integration tests (1), end-to-end tests (1), load and performance tests (1).

How quickly are Configuration and feature flags incidents detected in public reports?

The median time to detection is 136.5 minutes across 2 reports that state both the change time and the detection time.

How likely are Configuration and feature flags incidents compared with each other?

Config change without restart semantics: low likelihood, medium impact; Environment mismatch: production points to staging: low likelihood, unrated impact; Flag default flips on missing config: low likelihood, low impact; Flag enabled for wrong segment: low likelihood, medium impact; Rate limit misconfigured: medium likelihood, medium impact.

What should a release checklist for Configuration and feature flags include?

The group checklist collects the first pre-release item of each of the 5 published incident types; each item names the test class that checks it.