PATTERN Cited by 1 source
Emergency bypass¶
An explicit, audited escape hatch around the normal change-management pipeline for when incident-response speed matters more than review strictness. Sits adjacent to a Git-based or multi-stage approval workflow; not a replacement.
Design shape¶
- Separate endpoint. UI portal, CLI, or API distinct from the normal PR flow — unambiguous that the user is skipping gates.
- Narrow permission set. Usually restricted to on-call / SRE / service owners; not available to every engineer.
- Mandatory metadata. Require a ticket ID, incident ID, or free-text justification at submit time.
- Full audit log. Every bypass event captured: actor, timestamp, old value, new value, reason. Reviewed after the incident.
- Visible in observability. Emergency config events show up in the same dashboards as normal config events so responders (and later reviewers) see them in context.
Why it's a pattern, not an anti-pattern¶
Without an emergency path, teams build unofficial ones: direct database writes, skipping review by pushing to a "hotfix" branch, or manually restarting services with mutated environment variables. Those have worse audit trails than an official bypass. Making the bypass a first-class, audited feature is safer than pretending it isn't needed.
Seen in¶
- sources/2026-02-18-airbnb-sitar-dynamic-configuration — Airbnb's
sitar-portalis explicitly designed as an override for the default Git-based config workflow, for "fast emergency config updates that can bypass the normal CI/CD pipeline." Fully auditable for future review.