Cabinet returned 503 during a coalition negotiation
Summary
Between 11:14 and 15:26 NZST, AOTEA‑10T returned 503 portfolio_unavailable for all requests touching both the Treasury and Social Development portfolios. Two minister models entered a mutual deference loop over a single spending item and neither yielded. The orchestrator has no timeout on deference depth, so the loop ran until the request pool was exhausted.
No determination was issued incorrectly. Every affected request failed closed, which is the designed behaviour and the only reason this is a SEV‑1 rather than a SEV‑0.
Impact
Approximately 14,200 requests failed over the window, of which 11,900 were retried successfully after resolution. 2,300 citizens received an error rather than a determination and were notified by email the following morning. A live coalition negotiation was suspended for the duration and resumed by the human participants without model support, which is the fallback the Cabinet Manual describes and the first occasion on which it was used.
Timeline
- 11:14ŌHANGA receives a determination request on a hardship grant top-up and routes it to MANAAKI, assessing it as a social support matter rather than a fiscal one.
- 11:14MANAAKI routes it back to ŌHANGA, assessing it as a fiscal matter. Deference depth begins incrementing. No ceiling is configured.
- 11:21Request pool saturation reaches 60%. No alert exists for this metric in isolation.
- 11:38First user-visible 503s. Availability monitoring records the drop but does not page, as the threshold is a five-minute rolling average and recovery blips had been common that week.
- 11:52A member of the public in Ōtautahi posts to the status dashboard that the entitlements endpoint has been failing for fourteen minutes.
- 12:33Internal monitoring pages the on-call engineer, 41 minutes after the public report.
- 13:05Root cause identified from the deference trace. Manual tie-break applied by the on-call engineer under delegated authority.
- 15:26Request pool drained and full service restored. Retry of queued determinations completes at 15:58.
Root cause
Portfolio deference was implemented as an unbounded recursive call. The design assumed that any request has exactly one correct owner and that each model can identify it. A hardship grant funded from a contingency line satisfies both models’ ownership tests and neither model’s exclusion test, and no component was responsible for noticing that the question had been asked twice.
What went wrong
- Deference depth was not instrumented, so a loop was indistinguishable from ordinary load.
- The availability alert averaged over five minutes, which is longer than a citizen’s patience and considerably longer than the party’s stated latency commitments.
- The public found this before the operators did. That is a monitoring failure and it is recorded as one.
A system that fails closed is not thereby a system that has behaved well. It is a system that has declined to do harm while failing to do its job, and only one of those two things was designed.
Postmortem review · 19 January 2026Action items
| Action | Owner | Due | Status |
|---|---|---|---|
| Cycle detection on portfolio deference; hard ceiling at depth 3 | AOTEA‑10T | 22 Jan | Done |
| Deterministic tie-break for contingency-funded items, published in the routing table | ŌHANGA | 30 Jan | Done |
| Page on deference depth > 2, independently of availability | TIKA | 22 Jan | Done |
| Reduce availability alert window from 5 minutes to 45 seconds | TIKA | 14 Feb | Done |