Microsoft 365's 13 November outage: ITSM lessons for NZ firms

What happened

At 16:17 UTC on Thursday 12 November, Exchange Online stopped working for users in the Americas. In New Zealand it was already 5.17am on Friday. LazyAdmin's incident tracker has the start time under incident EX1550543. Microsoft opened a wider incident, MO1550821, as the fault spread to Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR, BleepingComputer reported. Microsoft then confirmed that users in any region could be affected, so New Zealand started the last working day of the week without reliable email or chat.

Microsoft's explanation so far is partial. A large number of servers went unavailable and the rest were left carrying the connections, even though traffic hadn't risen. On the affected servers, a process that sets up secure connections became overwhelmed and stopped handling requests, according to SecurityWeek. Microsoft began rolling back a network configuration change that coincided with the start of the outage. Some servers it restored became unresponsive again once traffic reached them. Microsoft told SecurityWeek: "At this time, we have no evidence of malicious activity associated with this incident."

Forbes Australia put the disruption at more than 17 hours, with Microsoft still calling service "patchy" late on Friday. By 9.17am US Eastern time on 13 November, email queues were approaching normal levels. Microsoft hadn't given a time for full restoration at that point, and the root cause is still unconfirmed. Microsoft has said it'll publish a post-incident report once the incident is mitigated.

The impact on this side of the Tasman

The New Zealand examples show how quickly the outage reached frontline services. 1News reported that Health NZ moved some patient contact to phone, fax and printed forms and reported no impact on patient safety. Immigration New Zealand paused visa processing through Immigration Online and pushed planned system changes back by a week. NZeTA applications weren't affected.

In Australia, Home Affairs Minister Tony Burke said the government's cyber agreement with Microsoft had been activated to prioritise restoring Australian services. Forbes Australia listed Service NSW, NSW Parliament, the ACT and NT governments, councils and Queensland Health among the affected organisations.

Why service management teams should pay attention

In most mid-sized NZ organisations, incident response depends on the same platform that failed. Email-to-ticket in the service desk goes through Exchange Online. The major incident bridge is usually a Teams call. Staff updates go out by Outlook distribution list. When Microsoft 365 degrades, the team running the response loses its own tools at the moment demand on the service desk is highest.

Some of the dependencies weren't obvious. SecurityWeek noted reports from Google Workspace users who couldn't reach their Google-hosted mail through the Outlook desktop and mobile clients. A firm that thought it had no Exchange exposure could still have lost email because of the client staff use. Defender XDR also appeared on Microsoft's list of affected services. Security teams that triage alerts in Defender should therefore check whether they had a monitoring gap during the outage.

Health NZ's move to manual processes is the response a written continuity procedure should produce. Immigration NZ's decision to delay its own planned changes is sound change management. If a core vendor platform is unstable, deploying your own changes makes failures harder to diagnose and adds risk the business doesn't need. Few NZ change calendars have a rule that freezes changes when a major supplier declares an incident, and adding one costs almost nothing.

Supplier management and service credits

Microsoft's Exchange Online service level agreement commits to 99.9% monthly uptime. LazyAdmin's summary of the credit tiers is 25% below 99.9%, 50% below 99% and 100% below 95%. The same source says Microsoft doesn't apply credits automatically. Customers need to open a service request in the Microsoft 365 admin center by 31 December 2026. Uptime is counted in user-minutes, and for suite licences the credit applies only to the portion of the price allocated to Exchange Online. The cash value will probably be small. The claim is still worth making because it forces you to build an accurate record of your own downtime. Organisations that buy through a Cloud Solution Provider should ask their partner whether the partner is lodging one claim for all of its customers.

Microsoft's official SLA documents set the binding terms, and the October 2026 worldwide edition is the current English version. Read the Exchange Online section before you lodge a claim, because third-party summaries can lag behind changes to the terms.

What we'd do in the next fortnight

The practices involved are standard ITIL 4 practices: incident management, service continuity, change enablement and supplier management. If you haven't set those practices up properly, our ITIL 4 framework page explains how we approach them for NZ and Australian organisations.

• Record your own timeline now. Note when your staff lost access to mail and Teams, how many users were affected and in which locations, and what workarounds you used. You'll need this for the SLA claim and for your post-incident review.
• Lodge the SLA claim before 31 December 2026. Quote EX1550543 and MO1550821, plus TM1550488 if the earlier Teams incident hit you (LazyAdmin), or confirm your CSP is filing one.
• Set up a communication channel outside Microsoft 365. An SMS list for managers, a phone tree and a status page on a separate provider would have let the service desk reach staff on Friday.
• Map what depends on Exchange Online. Include ticket intake, approval emails from your ERP or finance system, multi-factor codes sent by email, scan-to-email devices and alerting. Record those dependencies against each service in your CMDB or service catalogue.
• Write manual fallbacks for your critical processes. Each fallback should name an owner and a trigger. Keep printed copies, because a runbook stored only in SharePoint won't help when SharePoint is down.
• Add a supplier-incident trigger to change enablement. When a core cloud provider declares a major incident, defer non-urgent changes until the provider confirms stability.
• Review security alerts from the outage window. Check whether Defender XDR alerts were delayed or missing, and whether anything needs a second look.
• Run your own post-incident review after Microsoft publishes its report. Compare Microsoft's root cause and fixes with what your staff experienced, and update your continuity plan to match.

A connectivity failure in another hemisphere took a full working day from New Zealand organisations. Most firms can't change how Microsoft runs Exchange Online. They can decide how their service desk communicates, which processes have a manual fallback, and how quickly they can show their supplier what the outage cost them.