GitHub Merge Queue Cutoff Window Expiry Enforcement: Default Action Ladder, Intake Freeze Rules, and Audit-Proof Recovery Policy (2026)
Declaring a cutoff is only half of governance. The harder failure mode appears when the cutoff decision window expires and no one executes the promised path. Teams then drift into silent exceptions while risk accumulates.
This guide defines an expiry enforcement playbook for GitHub merge queue incidents. It gives default actions, severity-based fallback rules, and copy-paste templates so decision-window expiry cannot become an unowned state.
Table of contents
1. Why expiry enforcement is mandatory
A cutoff without expiry enforcement is only a promise. If the decision deadline passes and nothing is forced, responders learn that deadlines are optional and emergency exceptions can survive by inertia.
| Failure pattern | Impact | Enforcement control |
|---|---|---|
| Deadline passes with no accepted decision owner | No accountable execution path | Immediate default owner assignment |
| Deadline passes with owner but no execution proof | Unverifiable progress claims | Mandatory proof artifact within fixed SLA |
| Multiple expiry events in same incident | Governance trust collapse | Automatic intake freeze and leadership escalation |
2. Expiry trigger sets and detection rules
Keep expiry detection objective and machine-checkable. These three inputs are enough for most teams:
| Trigger combination | Minimum condition | Enforcement result |
|---|---|---|
| A only | Deadline passed | Auto-notify acting decision owner |
| A + B | Deadline passed, no proof | Default action ladder step 1 |
| A + B + C | Deadline passed, no proof, exception active | Immediate restore-or-freeze default |
| Repeat A + B within 24h | Second expiry event | Mandatory leadership handoff |
3. Default action ladder after expiry
Define one ladder so every responder knows what happens next when expiry fires:
| Ladder step | Time budget | Action | Expected artifact |
|---|---|---|---|
| Step 1 | 0-3 minutes | Auto-assign acting decision owner role | Ownership acceptance comment |
| Step 2 | 3-8 minutes | Choose default path: restore baseline or freeze intake | Decision comment with rationale |
| Step 3 | 8-15 minutes | Execute chosen path | Protection delta / queue state proof |
| Step 4 | 15-20 minutes | Publish follow-up checkpoint and reopen criteria | UTC checkpoint + owner |
Default paths should be conservative: if uncertainty is high, protect baseline first and optimize throughput later.
4. Severity-based fallback enforcement
Use severity to determine default action when no explicit decision is delivered before expiry:
| Severity | If window expires | Fallback owner | Default path |
|---|---|---|---|
| SEV-1 rollback blocked | No debate period | Incident commander | Restore baseline + freeze intake |
| SEV-2 queue unstable | Single short grace (max 5 minutes) | Governance lead | Freeze intake, keep current rollback lane only |
| SEV-3 policy drift risk | Immediate closure review scheduling | Service owner delegate | Deny extension, restore protections |
5. 20-minute post-expiry workflow
Run this fixed sequence after expiry detection:
- Minute 0-2: publish expiry event with breached deadline and UTC now.
- Minute 2-4: assign fallback owner role and require explicit acceptance.
- Minute 4-8: execute default action ladder step 2 selection.
- Minute 8-15: apply protection/queue changes and publish first proof.
- Minute 15-20: lock next checkpoint, owner, and follow-up review window.
6. Copy-paste enforcement templates
Use these templates in PR timelines or incident channels:
Template A: expiry event declaration
[CUTOFF WINDOW EXPIRED]
Incident: <id>
Severity: <SEV-1/2/3>
Original decision deadline (UTC): <yyyy-mm-dd hh:mm>
Detected at (UTC): <yyyy-mm-dd hh:mm>
Execution proof present: <yes/no>
Active exception present: <yes/no>
Fallback owner role: @<role-handle>
Default action step start (UTC): <yyyy-mm-dd hh:mm>
Template B: fallback owner acceptance
[FALLBACK OWNER ACCEPTED]
Acting owner: @<handle>
Accepted at (UTC): <yyyy-mm-dd hh:mm>
Selected default path: <restore-baseline / freeze-intake>
First execution proof ETA (UTC): <yyyy-mm-dd hh:mm>
Disallowed actions: permanent policy edits
Template C: default-path execution proof
[DEFAULT PATH EXECUTED]
Path: <restore-baseline / freeze-intake>
Executed at (UTC): <yyyy-mm-dd hh:mm>
Branch protection state: <summary>
Queue intake state: <open/frozen/limited>
Proof links: <links>
Next checkpoint owner: @<handle>
Next checkpoint (UTC): <yyyy-mm-dd hh:mm>
Template D: expiry enforcement closure
[EXPIRY ENFORCEMENT CLOSURE]
Incident: <id>
Expiry event count in incident: <N>
Final enforced path: <restore / freeze / limited intake>
Current risk status: <stable / unstable>
Follow-up governance review owner: @<handle>
Follow-up due (UTC): <yyyy-mm-dd hh:mm>
7. KPIs and anti-drift safeguards
Track these weekly to verify expiry enforcement is real:
| KPI | Target | If missed |
|---|---|---|
| Expiry-to-first-proof median | <= 15 minutes | Reduce owner hops and force pre-assigned fallback roles |
| Incidents with post-expiry ad-hoc grace | 0 | Treat as governance defect; require policy update |
| Repeat expiry events within same incident | Downward trend | Escalate to leadership and tighten decision windows |
| Closure records with full UTC evidence fields | 100% | Block closure until fields are complete |
Cutoff governance fails when expiry is treated as advisory. A strict enforcement ladder turns expired decisions into predictable recovery behavior, not policy drift.
FAQ
Should every expired window force an intake freeze?
No. Use severity-based defaults. SEV-1 often needs immediate freeze, while SEV-3 can default to restore-and-review without full freeze.
Can we reopen intake before closure review is complete?
Only with explicit reopen criteria and owner acknowledgment. Reopen without criteria usually recreates the same expiry loop.
What if the fallback owner is unavailable?
Use predefined role fallback order. If no fallback accepts within timeout, enforce baseline restore automatically and log emergency fallback.
How do we avoid overusing freeze defaults?
Track freeze frequency by service and tune deadlines, on-call coverage, and evidence requirements. Freeze should be protective, not routine.
How does this relate to the cutoff matrix guide?
The cutoff matrix guide defines who gets authority at trigger time. This guide defines what must happen if that authority fails to execute before expiry.
Run this expiry playbook with your ACK-timeout remediation and closure-quality metrics guides to keep merge queue incident governance deterministic end to end.