One P1 outage a day at Health NZ: what to test in your own IT

What was reported

RNZ reported on 6 November that Health NZ facilities averaged more than one priority one outage a day over the past year, based on information released to the Public Service Association (PSA) under the Official Information Act. The same story covers two union surveys with 2,600 responses between them. It also carries a PSA claim that average fix times tripled to more than three weeks by March, with the helpdesk backlog passing 4,000 unresolved tickets at one point.

Much of the evidence is disputed, and readers should weigh it accordingly. Health NZ told the PSA the fix-time figures were provisional and hadn't been validated. The surveys had response rates of 6.7% and 13.1%, so the 77% of PSA respondents who said IT problems affect patient care speak for the staff who replied. Health Minister Simeon Brown's office says the report has no before-and-after outage data and shows no link between outages and staffing. Health NZ blames the major outages earlier this year on third-party hardware and data centre failures.

The staffing argument can't be settled from what's been published, and businesses outside health don't need it settled to learn something. The incident record is the useful part.

Why the daily count needs care

Health NZ's priority one category covers more than hospital-wide failures. According to the released documents, a priority one outage can affect a single department, a hospital, a district or a region, where there's immediate harm or risk to patient and staff, with no safe work around. The definition also takes in some short outages of under two hours where the impact is significant.

A daily average across that range can include single-department failures as well as regional ones, and the published reporting doesn't give the split. Health NZ's digital director says the organisation runs thousands of applications, which also makes a raw count hard to read without a denominator. We think the lesson for any IT leader is about reporting. A P1 count tells a board very little unless the definition, the scope of each incident and the trend over time sit beside it.

What the big outages showed

The 22 July Waikato outage is the most useful case. Connectivity between the user network and the main data centre failed at 10:44am, and the primary and secondary equipment both failed, leaving systems running but unreachable. The backup didn't activate, and Health NZ restored service manually with its technology partners.

Five hospitals were offline for 11 hours, and Waikato Hospital deferred 68 appointments and 15 theatre cases. Health NZ later said the fault sat in its own network. The failed part was at least four years old against a target replacement cycle of five to seven years, so the equipment was within its planned life. In July the cause was still under investigation with the vendor, and we're not aware of any published findings since.

The side effects were as telling as the headline failure. Paging and some patient call bells stopped working, so staff fell back on cell phones. The impact varied by service depending on whether applications were hosted on local servers. Staff also reported that recent AI-transcribed reports were inaccessible. Those dependencies only appear in a continuity plan if someone has mapped them beforehand.

January's outages add two more points. After a roughly 12-hour outage across Auckland and Northland hospitals, Health NZ said it had put monitoring on the hardware component that failed, which raises the question of what else lacks monitoring. In the South Island outage on 13 January, systems were restored by 6pm, but an employee said at least one application still wasn't pulling data correctly the next day.

Health NZ had also seen the resilience gap before any of these incidents. An April 2025 internal report noted a lack of business continuity plans and minimal hot failover, and it forecast service desk call abandonment rising from 15% to 19%. Health NZ says mitigations were built into its final restructure proposal, including priority for critical clinical systems.

Money won't close the gap quickly. Budget 2026 set aside $153.6 million over four years for cyber security monitoring and IT safety upgrades, and Health NZ is putting in $300 million of its own budget over the first three years of its digital plan. B2B News, citing the Cabinet paper, reports that about 90% of baseline digital funding goes on keeping old systems running.

What it means for NZ businesses

A 50-person firm doesn't have Health NZ's scale, but the failure patterns carry straight across. Plenty of smaller organisations own a redundant pair of firewalls, switches or internet links that has never been forced to fail over during working hours. Many also have a data centre or cloud contract with strong uptime terms that wouldn't help when the fault is on the customer's side of the connection, as Health NZ says it was in Waikato. A supplier's service level covers the supplier's own kit and little else.

Inland Revenue offers a useful contrast this month. It's taking myIR, Gateway Services and its self-service phone line offline from 3pm Saturday to 9am Sunday on 21 to 22 November and again on 28 to 29 November for disaster recovery testing. Scheduling planned downtime to prove recovery works is a discipline any organisation can copy at a smaller size. Firms that file or run payroll through those services should also note the dates.

Labs, imaging providers, GPs, private hospitals and health software vendors have a more direct exposure. B2B News argues they should treat Health NZ as a counterparty risk, and we agree that offline fallbacks for results and referrals are worth building now.

Practical next steps

These fit into a normal quarter, and our ITIL 4 framework guide covers the wider practices behind them.

• Run a live failover on your most critical system in a planned window, including the network path staff use to reach it. Record how long it took and which steps needed a person.
• Check redundant equipment for shared weak points. Pairs bought together can share age and firmware, so being inside the replacement cycle proves little on its own.
• Rewrite your P1 definition so severity and scope are recorded separately. A department outage and a site-wide outage shouldn't look the same on a board report.
• Keep major incidents open until data is flowing correctly and any backlog has been reconciled, and report that time alongside the restore time.
• Map the quiet dependencies: desk phones, paging, door access, transcription and AI tools, and anything hosted centrally that staff assume is local. Then try the paper fallback once with real staff.
• Report ticket age, backlog and abandoned calls monthly, using validated figures, so a slide in service shows up before an outage does.
• Ask suppliers what they'd need from you during an outage on your side of the connection, and agree the escalation path in writing.