GitHub Merge Queue Post-Expiry Reopen Criteria: Safe Intake Restore Gates, Evidence Checklist, and Owner Sign-Off Policy (2026)
Expiry enforcement stops governance drift, but it does not automatically prove the system is ready to reopen queue intake. Teams that reopen too early often re-enter the same failure loop within minutes.
This guide defines a post-expiry reopen policy for GitHub merge queue incidents. It gives objective gates, role ownership, and copy-paste templates so reopen decisions stay auditable and safe.
Table of contents
1. Why reopen criteria must be explicit
When teams treat reopen as a subjective call, pressure biases the decision toward speed over safety. Explicit gates prevent optimism from overruling evidence.
| Unsafe reopen pattern | What fails next | Policy correction |
|---|---|---|
| "Looks stable" reopen with no checks | Required checks fail again; queue re-freezes | Require health proof from required-check set |
| Single-owner verbal approval | No audit trail; ownership disputes after relapse | Dual sign-off with UTC comment template |
| No fallback path after reopen | Delayed recovery when errors spike | Pre-declare immediate restore/re-freeze path |
2. Core reopen gates and ownership
A reopen decision is valid only when every mandatory gate passes and responsible owners are present for the observation window.
- Rollback integrity: Verified target commit/state is deployed and stable in production canaries.
- Required-check health: Last N queue-relevant checks completed without timeout/cancel loops.
- Owner coverage: Incident owner + independent reviewer available for at least 60 minutes post-reopen.
- Fallback readiness: Restore baseline/re-freeze action is executable in under 10 minutes.
- Communication: Reopen scope, blast radius, and re-freeze trigger are posted in incident thread.
3. Severity-based reopen matrix
Reopen strictness should follow incident severity. Higher severity demands stronger proof and longer guarded observation.
| Severity | Minimum proof before reopen | Observation window | Auto re-freeze trigger |
|---|---|---|---|
| SEV-1 | All gates + leadership sign-off + fallback dry-run evidence | 60 min | Any required-check timeout/cancel or error-budget burn spike |
| SEV-2 | All gates + dual owner sign-off | 45 min | Two consecutive queue failures in same service slice |
| SEV-3 | All gates + reviewer confirmation | 30 min | One repeated failure on prior incident signature |
4. 30-minute reopen workflow
Use this short workflow after expiry defaults have been enforced and baseline state is stable.
- T+00: Validate gate checklist with links (check dashboard, required-check run URLs, owner confirmations).
- T+05: Post "reopen proposal" comment with severity, scope, fallback, and observation owner.
- T+10: Independent reviewer approves or rejects with explicit reason.
- T+12: Reopen intake for a limited service subset (not full blast radius).
- T+20: Review queue health and required-check completion latency.
- T+30: Promote to full reopen only if no guardrail breach; otherwise immediately re-freeze and restore defaults.
5. Copy-paste reopen templates
Use these templates to standardize audit logs and avoid ambiguous comments.
Template A: Reopen approved
[Merge Queue Reopen - Approved]
Incident: [INC-###]
Severity: [SEV-1/SEV-2/SEV-3]
Decision UTC: [YYYY-MM-DD HH:MM]
Approved By: [owner], [reviewer]
Gate Results:
- Rollback integrity: PASS ([link])
- Required checks health: PASS ([link])
- Owner coverage (60/45/30m): PASS ([link])
- Fallback readiness: PASS ([link])
Reopen Scope:
- Phase 1 repos/services: [list]
- Observation window: [minutes]
- Auto re-freeze trigger: [rule]
If trigger fires, immediately restore defaults and freeze intake.
Template B: Reopen denied
[Merge Queue Reopen - Denied]
Incident: [INC-###]
Severity: [SEV-1/SEV-2/SEV-3]
Decision UTC: [YYYY-MM-DD HH:MM]
Denied By: [owner], [reviewer]
Blocking Gates:
- [Gate]: FAIL/UNKNOWN ([link])
- [Gate]: FAIL/UNKNOWN ([link])
Action:
- Keep intake frozen
- Restore baseline defaults remains active
- Next review checkpoint UTC: [YYYY-MM-DD HH:MM]
- Owner for remediation: [name]
6. KPIs and auto re-freeze triggers
Define measurable thresholds so reopen quality can be monitored instead of debated.
| KPI | Target | Trigger threshold |
|---|---|---|
| Queue-required check success rate (first 30m) | >= 98% | < 95% -> re-freeze |
| Median required-check completion time | <= baseline + 20% | > baseline + 40% -> investigate + possible re-freeze |
| Relapse count on prior incident signature | 0 | >= 1 for SEV-1/2 -> re-freeze |
7. FAQ
Can we reopen with one failed gate if product pressure is high?
No. A failed gate means known unresolved risk. Reopen with failed gates only hides risk transfer; it does not reduce risk.
Should reopen criteria be the same for every repository?
Core gates stay consistent, but scope and thresholds can be tuned by service criticality and incident severity.
Who owns re-freeze decisions after reopen?
The observation owner executes immediate re-freeze when trigger conditions fire; reviewer confirms and records evidence.
How long should observation last?
At least 30 minutes for SEV-3, 45 for SEV-2, and 60 for SEV-1. Extend if check latency or failure signals are unstable.
What if metrics are inconclusive during observation?
Treat inconclusive as non-pass, keep intake frozen, and run another checkpoint after missing evidence is collected.
Conclusion
Expiry enforcement prevents unowned drift, but resilient teams also define exactly how intake can be reopened. Objective gates, dual sign-off, and trigger-based re-freeze rules convert reopen from guesswork into governed execution.
If you already adopted cutoff-window expiry defaults, implement this reopen layer next. It closes the lifecycle loop from escalation to safe restoration.