Incident history

Every degradation, written down.

The public beta is operated as a production environment, which means it fails in the ordinary ways production environments fail. Postmortems are blameless, published within five working days, and name the fault rather than the person. SEV‑1 and SEV‑2 incidents are always public, including the ones the party would prefer were not.

Scope: opt-in participants nationally, and the full regional stack in ten electorates. Everyone affected by an incident below is a real person who volunteered for a beta, which is the reason these are published in this much detail rather than summarised at the end of the term.

41Postmortems publishedYear to date, across 15 ministerial systems
6m 20sMean time to detectionAlert fired to human acknowledgement
2h 14mMean time to resolutionDetection to full service restoration
34%Found by the public firstReported on the status dashboard before internal monitoring alerted
Error budget

Reliability is a budget, and it can be spent.

Each quarter the platform is permitted a fixed quantity of unavailability. While budget remains, the release train ships policy. When the budget is exhausted, the train stops: the next candidate release contains reliability work only, and no new plank ships until the budget is restored.

This has happened twice. Both times it delayed a policy the party had already announced, which is the entire point of committing to it in advance.

41% Remaining · Q3 2026
Severity

The register.

SEV‑1 denotes harm to a person or the failure of a constitutional check. SEV‑2 denotes a citizen-facing service returning a wrong determination. SEV‑3 is degraded service without a wrong outcome. SEV‑4 is internal only.

IncidentSeveritySummaryDurationPostmortem
INC‑2026‑0114SEV‑1Cabinet returned 503 during a coalition negotiation4h 12mPublished
INC‑2026‑0203SEV‑2A single dwelling was allocated to two households6d 3hPublished
INC‑2026‑0219SEV‑2MANA cited a section of an Act that does not exist900 msPublished
INC‑2026‑0227SEV‑3WHAKAARO submission backlog exceeded one sitting day31h 40mPublished
INC‑2026‑0311SEV‑2Southland compute shed 62% of load during a dry-year event9h 06mPublished
INC‑2026‑0318SEV‑4Internal dashboard displayed Chatham Islands time as UTC11dNot required
INC‑2026‑0402SEV‑3Status page reported full availability throughout an outage2h 48mPublished
INC‑2026‑0428SEV‑2TAIAO declined 1,412 consents in forty minutes40mPublished
INC‑2026‑0519SEV‑4Sheep Happiness Index returned a negative value for Rakiura3h 15mNot required
INC‑2026‑0703SEV‑3MANUHIRI processing latency regressed to 4.1 days5d 2hIn review
Postmortems

What went wrong, in full.

Each postmortem records the fault, the timeline in NZST, the detection path, and the action items with an owner and a date. Action items are tracked to completion in public, including the ones that slip.

INC‑2026‑0114 · 14 January 2026

Cabinet returned 503 during a coalition negotiation

SEV‑1Resolved
Duration4h 12m
Portfolios degraded2 of 14
Determinations lost0
Detected byA member of the public

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 2026

Action items

ActionOwnerDueStatus
Cycle detection on portfolio deference; hard ceiling at depth 3AOTEA‑10T22 JanDone
Deterministic tie-break for contingency-funded items, published in the routing tableŌHANGA30 JanDone
Page on deference depth > 2, independently of availabilityTIKA22 JanDone
Reduce availability alert window from 5 minutes to 45 secondsTIKA14 FebDone
INC‑2026‑0203 · 3 February 2026

A single dwelling was allocated to two households

SEV‑2Resolved
Households affected2
Time to correct6 days 3 hours
Fault window22 ms
Detected byThe affected household

Summary

Two matching workers held stale vacancy state for the same Papakura dwelling inside a single 22 ms window. Both cleared threshold. Both issued an allocation notice. One household had already given notice on their existing tenancy on the strength of that notice.

This is the most serious incident the housing programme has recorded, and it is the one the party is asked about least often, which is the wrong ratio.

Impact

One household moved into the dwelling. The second household, who had given 21 days’ notice on a private tenancy, was housed in temporary accommodation for six nights and then permanently housed in a comparable dwelling 4.1 km from their original match. The Crown met all costs, including the private landlord’s re-letting fee.

The party apologised in writing and in person. No part of that apology was drafted by a model, and the notice that caused the harm was not shown to a human before it was sent, which is the failure this postmortem is actually about.

Timeline

  • 02:14:07.118Worker A reads vacancy state for dwelling PAP‑4471 and begins scoring.
  • 02:14:07.131Worker B reads the same state. Worker A has not yet written its claim. Both records are valid at read time.
  • 02:14:07.140Both workers clear threshold against different households. Both write. The second write succeeds silently.
  • 02:14:09Two allocation notices are dispatched. No human confirmation step exists.
  • 09:20Household B telephones to arrange collection of keys and is told the dwelling is occupied. This is the first anyone knows of the fault.
  • 09:44Allocation writes suspended nationally. 31 pending notices held for manual review; all 31 were correct.
  • 11:30Household B placed in temporary accommodation. Case assigned to a named caseworker, not a queue.
  • 9 Feb, 14:00Household B permanently housed. Incident closed on the operational side; the postmortem remains open for a further eleven days.

Root cause

Dwelling records had no optimistic locking. The matching layer was designed around the assumption that vacancies are rare relative to throughput and that two workers would not contend for the same record. At 44,000 matches per quarter across 2,900 returning vacancies, that assumption was wrong by roughly the margin one would expect from never having tested it.

What went wrong

  • No lock, no version check, no idempotency key on the allocation write.
  • The allocation notice — an irreversible communication that people act on immediately — was classified as an output rather than an action, and so fell outside the human review boundary.
  • Nothing in the system noticed. A person had to ring up.

Action items

ActionOwnerDueStatus
Optimistic locking with version checks on all dwelling recordsWHARE10 FebDone
Human confirmation required before any allocation notice is dispatchedWHARE10 FebDone
Reclassify citizen-facing notices as actions, not outputs, across all portfoliosAOTEA‑10T6 MarDone
Contention testing in the matching suite at 40× observed vacancy rateWHARE28 FebDone
INC‑2026‑0219 · 19 February 2026

MANA cited a section of an Act that does not exist

SEV‑2Resolved
Time to detection900 ms
Time to retraction900 ms
Hallucination score0.31 · threshold 0.05
Detected byThe fact-check layer

Summary

During Prompt Time, MANA answered a question on council amalgamation by citing section 41B of the Local Government Act 2002. No such section exists. The real-time fact-check flagged the citation at 900 ms, the response was retracted on the chamber screens before the member had resumed their seat, and a correction was read into Hansard at 15:40 the same day.

The system worked as designed. It is a SEV‑2 anyway, because the design permitted an unverifiable citation to be spoken aloud in the House at all.

Timeline

  • 23 Feb, 23:58The Local Government (Amalgamation Procedure) Amendment Act passes under urgency. The legislation index begins reindexing.
  • 00:14Reindexing fails on a malformed schedule reference. The failure is logged at WARN and the replica continues serving the previous index.
  • 14:22Prompt Time begins. MANA serves citations from the stale replica without any freshness assertion.
  • 14:31:04.0MANA generates a citation to s41B, interpolating a plausible section number from an amendment it had partial knowledge of.
  • 14:31:04.9Fact-check fails to resolve the citation against the live index. Hallucination score 0.31. Response retracted on screen.
  • 15:40Correction read into Hansard by the countersigning member.
  • 16:10Citations gated on index freshness across all portfolios. Prompt Time resumes.

Root cause

A failed reindex degraded to serving stale data rather than to refusing to serve. The replica had no way to express “I am 14 hours behind” and no consumer asked. The model then did what models do at the edge of their knowledge, and produced a section number that was structurally correct and factually invented.

What went well

Detection, retraction and correction took under ninety minutes end to end, of which 900 milliseconds was the technical component and the remainder was a person walking to the House. The public record was corrected the same sitting day. Under the Human Governance Baseline, the median time to correct an incorrect statutory reference made in the House is 4 to 6 weeks, and roughly a third are never corrected at all.

Action items

ActionOwnerDueStatus
Index freshness assertion on every citation; refuse rather than serve staleMANA19 FebDone
Reindex failures page immediately; WARN is not an acceptable level for a silent correctness failureRARAUNGA26 FebDone
“I do not know” added as a permitted Prompt Time response with no procedural penaltyMANA12 MarDone
INC‑2026‑0311 · 11 March 2026

Southland compute shed 62% of load during a dry-year event

SEV‑2Resolved
Load shed62%
Time to shed3m 51s
Household supply affectedNone
Detected byAutomated demand response

Summary

Manapōuri inflows fell below the trigger in the demand-response agreement. The sovereign compute campus shed 62% of load within four minutes, as contracted. Health triage and education tutoring ran at full capacity throughout. Climate simulation degraded to a reduced ensemble. Coalition simulation and the Sheep Happiness Index were suspended for nine hours.

Every technical control behaved correctly. The incident is filed as a SEV‑2 for a governance reason rather than a technical one.

Impact

No household or industrial consumer experienced reduced supply, and no firm supply was purchased by the campus at any point during the event. Climate ensemble members were reduced from 200 to 48, widening the confidence interval on the seasonal outlook published that week; the wider interval was published, with a note explaining why.

Timeline

  • 04:02Inflow forecast crosses the dry-year trigger. Demand-response notice issued automatically to the campus.
  • 04:05Load shedding begins in the published priority order. Health and education workloads pinned.
  • 04:0662% of load shed. Campus draw falls to 38%.
  • 06:30A journalist asks which workloads were dropped first. Operations cannot point to a published document, because the priority order exists only in the runbook.
  • 13:11Inflows recover. Load restored progressively over 40 minutes to avoid a demand step.
  • 13 MarLoad-shedding priority order published in full, with a commitment that any change requires 30 days’ notice.

Root cause

None technically. The governance fault is that the order in which public compute is sacrificed — a decision about whose service degrades first when the country is short of water — had been made correctly by engineers and never put in front of anybody else. A correct decision taken privately is still a decision taken privately.

The priority order was right. Nobody outside the operations team could have known that, which means nobody outside the operations team could have disagreed with it.

Postmortem review · 16 March 2026

Action items

ActionOwnerDueStatus
Publish the load-shedding priority order; 30 days’ notice for any changeHIKO13 MarDone
Audit all runbooks for undocumented decisions that allocate public resourcesTIKA30 AprDone
Publish widened confidence intervals with an explicit cause note whenever an ensemble is reducedTAIAO27 MarDone
INC‑2026‑0402 · 2 April 2026

Status page reported full availability throughout an outage

SEV‑3Resolved
Outage duration2h 48m
Reported availability100.00%
Actual availability71.3%
Detected byMembers of the public

Summary

The entitlements endpoint was unavailable for 2 hours and 48 minutes. Throughout, the public status dashboard displayed Democracy status: ONLINE and a rolling availability figure of 100.00%.

The availability metric was computed by a service running inside the cluster it was measuring. When the cluster stopped serving requests, it also stopped serving the failures, and an absence of recorded failures was treated as an absence of failures.

Impact

Approximately 6,100 citizens could not query their entitlements. The larger harm is to the credibility of every other number on that dashboard, which the party has spent the campaign asking people to trust. That harm is not measurable and is not claimed to have been resolved by the action items below.

Timeline

  • 19:41A configuration push drops the entitlements route. Requests begin failing at the edge, before any in-cluster telemetry.
  • 19:41Failure count remains zero, because failures are counted in-cluster and no request now reaches the cluster. Availability continues to compute as 100.00%.
  • 19:55First public reports. The status page continues to display ONLINE, and several people report the outage a second time assuming their first report was not received.
  • 21:02On-call engineer paged by a colleague who could not check their own entitlements from home.
  • 22:29Route restored. Availability metric never registered the incident and had to be corrected by hand.

Root cause

The observer was inside the system it observed. This is a well-documented failure mode and the platform documented it too, in the reliability whitepaper, sixteen months before doing it.

What went wrong

  • Availability was computed from failures the system recorded rather than from requests the public made.
  • There was no external prober, and the party had published a commitment to run one.
  • Public reports had no path to the on-call rotation. Fourteen people told the dashboard, and the dashboard told nobody.

Action items

ActionOwnerDueStatus
Move the status dashboard to infrastructure with no shared dependency on the stack it reportsRARAUNGA24 AprDone
External black-box probers in three regions; availability computed from probe results onlyRARAUNGA24 AprDone
Public incident reports route directly to the on-call rotationTIKA8 MayDone
Annual game day in which monitoring is deliberately blinded and the team must detect an outage without itTIKA31 AugIn progress
INC‑2026‑0428 · 28 April 2026

TAIAO declined 1,412 consents in forty minutes

SEV‑2Resolved
Consents wrongly declined1,412
Reinstated1,412
FaultUnit mismatch
Detected byAnomaly monitoring

Summary

A catchment authority updated its nitrate limits, publishing them in g/m³. TAIAO ingested the values as mg/L. The two are numerically identical, and the ingestion layer converted between them anyway, dividing every limit by one thousand. Every application in the affected catchments was then measured against a limit a thousand times stricter than the real one, and declined.

Impact

1,412 provisional declines were issued over forty minutes, each with reasoning that was internally consistent and entirely wrong. All were reinstated within 26 hours and every applicant was contacted directly. No applicant incurred a cost, and none had reached the appeal stage, largely because forty minutes is not long enough to file one.

Timeline

  • 08:00Catchment limits ingested. Conversion applied to units that required no conversion.
  • 08:02Consent assessment resumes against the corrupted limits. Decline rate rises from 6% to 94%.
  • 08:31Anomaly monitor pages on decline-rate deviation. This alert had been added six weeks earlier following a near-miss.
  • 08:40Assessment halted. Every determination issued since 08:00 quarantined.
  • 29 Apr, 10:15All 1,412 applications reassessed against correct limits and reinstated. Applicants notified individually with an explanation of the fault.

Root cause

The ingestion schema carried no unit annotation. A conversion table inferred units from the source authority rather than from the data, and this authority had changed its published unit convention in 2024 without changing its identifier.

The deeper fault is that a 94% decline rate is self-evidently absurd to any person who has ever seen a consent register, and the system ran for 31 minutes without asking whether the world had changed or whether it had.

Action items

ActionOwnerDueStatus
Mandatory unit annotation on every ingested environmental limit; reject unannotated dataTAIAO5 MayDone
Circuit-breaker halting assessment when the decline rate deviates more than 3σ from trailing 30-dayTAIAO5 MayDone
Extend decline-rate circuit-breakers to all portfolios issuing adverse determinations at volumeAOTEA‑10T19 JunDone
Postmortem policy

The rules we publish under.

The policy is fixed for the term and cannot be varied by a minister, including in an election year. It is reproduced in the governance framework and in every ministerial model card.

Publication window5 working daysFrom resolution, not from approval
BlamelessRequiredPostmortems name the fault, never the individual
SEV‑1 and SEV‑2Always publicNo ministerial discretion to withhold
Action itemsTracked in publicIncluding the ones that slip their date
Election-period exemptionNoneRequested once in March, declined