Microsoft 365 Outage – When The Suite Goes Dark, Restoration Order Becomes The Control

Who it reached. The reach went well past office inconvenience. Australia’s security intelligence agency and its federal police confirmed that their organizations were affected. The UK Parliament said, “Alternative communication arrangements are in place.” London’s Metropolitan Police asked people with time-critical reports to telephone. Singapore’s Government Technology Agency said government emails were down, the Philippines Supreme Court said its email responses were affected, and the US House of Representatives said the outage impacted its users.

What governments said. Governments spoke of watchfulness and contingency. Downing Street said, “There are a range of services experiencing disruption.” The UK government spoke of “robust contingency plans” and said it was working with Microsoft to assess the effect on public services. Japan’s Deputy Chief Cabinet Secretary said his government was “keeping a close eye on the developments.” New Zealand’s foreign ministry said its “ability to receive emails has been affected by the global Microsoft outage.” Australia’s Assistant Treasurer called the economic impact “difficult to quantify.” A UK defense minister, Luke Pollard, was blunter: “I want to see this fixed.” Only Australia pointed to a written agreement with Microsoft, which the section on restoration order takes up.

What held. The systems that stayed up are as instructive as the ones that failed. “All critical operations at the Bank are running normally,” the Bank of England said. Services Australia said the outage “has not impacted customer-facing services and payments.” NHS England said its clinical and operational systems were working effectively. Systems of record that sit apart from the suite kept running. What stopped was the connective tissue, the approvals, handovers, and notices that travel by mail and meeting between those systems.

How large. No count of affected organizations exists. Microsoft has given no number or share of tenants affected, and the figure in wide circulation, more than 430 million people using Microsoft 365 apps, is its installed base and not a measure of impact. Greyhound Research therefore sizes this incident by what stopped, for whom, and for how long. Tallies of user complaints circulated all night, and this research note leaves them aside because they measure attention, not exposure.

The assumption under test. For a decade, enterprises have moved mail, meetings, documents, device management, security controls, and now the AI assistant onto this one suite, and they were right to. Consolidation cut cost, closed integration gaps, and gave security teams one estate to watch. A quieter assumption traveled with it: that the vendor’s standard terms, a monthly uptime percentage, a credit claimed afterward, and a promised review, were protection enough. Greyhound Research put the point publicly on November 13: “Enterprises have priced Microsoft 365 as a licence and never as a single point of failure.”

The thesis. By Greyhound Research’s count of the public record, this is the fourth multi-service Microsoft 365 incident of 2026, and it tests that assumption harder than the earlier three because the control layer went down with the work. Consolidation remains the right strategy for most enterprises. The standard terms around it are no longer enough. Three things decide a buyer’s exposure when a consolidated suite fails as one system, and none comes with the license: knowledge of the vendor’s change gate, a place in the order of restoration and notification, and fallbacks the buyer has written down and rehearsed.

A five-part test. A buyer can test its own position with five questions. Which processes cannot stop for a day, and what do they run on when the suite is down? What does each security control do when it cannot complete its check, and who chose that? How will the organization learn the state of the service when its own tenant is the thing that is down? Where does it stand in the order of restoration, and has anyone asked? What evidence must it hold to claim, to report, and to negotiate, and when does that evidence age out?

The reversal. Three further readings undid that position by degrees. By 20:56 UTC Microsoft was investigating a small number of recent configuration updates as possible contributors. At about 22:10 UTC it reported that “a core process on affected servers is becoming overwhelmed, causing capacity loss.” Overnight it identified the process as the one “responsible for establishing secure connections,” and by 01:18 UTC on November 13 it had “begun reverting a recent network configuration change that correlates with the start of impact.” At 03:07 UTC it “confirmed that change is not taking as expected.”

The recovery. Recovery language arrived in careful steps. Microsoft reported “positive results for server stability” at about 07:45 UTC, then “early signs of stabilization” with capacity below normal at 09:28 UTC, and “encouraging recovery progress” soon after 12:00 UTC. By 17:57 UTC it reported “broad recovery and stability across our services,” and at 22:00 UTC on November 13 it was watching the email backlog “before considering the issue resolved.” At 06:09 UTC on November 14, by two reports, it said it had “completed our efforts to address the underlying issue of the incident and restored service to the remaining impacted customers and regions,” and pointed to the incident record for further updates. Charles Lamanna, an executive vice president, said there was “no indication this is the result of malicious or cyber activity.” Australia’s Home Affairs Minister, briefed by the company, described “an update that has gone awry.”

The mail backlog. Access and delivery recovered on different clocks. At 14:01 UTC on November 13 Microsoft reported “email queues significantly reduced.” Six hours later it was “still draining queued messages” and added, “Service access can recover before mail flow fully normalizes.” At 22:00 UTC on November 13 the backlog was among the reasons Microsoft gave for keeping the incident open. By 02:17 UTC on November 14 it was still tracking “processing of the email backlog accumulated during the event,” and neither its last update nor its statement of that day mentions the backlog. The practical reading for a buyer is that a mailbox that opens is not proof that its mail is complete. Anything time-bound that was expected during those hours, a payment instruction, a filing, or a notice with a deadline, should be confirmed by another route.

How the record closes. Microsoft’s incident record now reads “Service restored.” Its last update, at 04:17 UTC on November 14, repeats the cause in the same words and adds two lines: “Start time: Thursday, November 12, 2026, at 10:05 AM UTC” and “End time: Friday, November 13, 2026, at 4:10 PM UTC.” That window is about 30 hours. The start it gives is more than four hours before the Teams incident, the first that the timelines record, and the record had earlier shown 18:26 UTC. Its end is almost six hours before the update of 22:00 UTC that day, in which Microsoft was watching the backlog “before considering the issue resolved,” and about fourteen hours before its statement that service was restored. Neither time is explained in the record as read. For a buyer the stated window matters, because a credit claim must give the time and duration of downtime.

What Microsoft tried. The record of mitigation shows how hard the fault was to hold. Microsoft first moved traffic away from the affected infrastructure and restarted servers. It then validated a different way of checking server health so that some servers could return, and observed that those servers “can become unresponsive again once they begin receiving traffic.” From about midnight UTC it limited which kinds of traffic reached the affected infrastructure in some locations and began rebuilding servers “using a previous software configuration.” The revert of the network configuration change came after all of these, and at 03:07 UTC Microsoft said the change was not taking as expected. Each step returned some capacity and then lost it, which is the alternation Exhibit 1 draws.

The mechanism, as far as it can be read. Taken together, the statements describe a failure that fed itself. Servers dropped out, the survivors took their load, a process that sets up secure connections was overwhelmed, and restarted servers failed again once traffic reached them. Greyhound Research reads that pattern as a reconnection surge, in which every client that lost its session returned at once asking for a new one. That is an inference from Microsoft’s words and not Microsoft’s finding. It would explain why removing the suspected trigger did not restore the service, and why recovery had to be metered region by region. Microsoft later said, “Given the scale of demand, we restored services gradually, validating stability at each stage.” Such an account fits the reading without confirming it.

On the question of attack. Microsoft’s language on attack hardened through the day. At about 03:40 UTC on November 13 an executive vice president wrote that there was “no indication this is the result of malicious or cyber activity.” About two hours later the company said, “As of now, we are not aware of any malicious activity that is causing this incident.” Soon after 12:00 UTC it had “no evidence of malicious activity associated with this incident.” Only at 17:57 UTC did it state a conclusion: “This was a technical issue not related to cyber or AI / agents.” The first three describe what Microsoft had seen so far. A security team can put the fourth on file as a finding, with the caveat that it came before any review.

Credit where it is earned. Microsoft earns credit on four counts. It paused all deployments and configuration changes about forty minutes after opening the wider incident, which was the conservative call. Updates arrived through the night at close to the hourly cadence its documentation sets. Twice, the company said plainly that a step had failed. And it extended the email timeout window to 48 hours, “to help protect delayed messages as delivery catches up.” None of that is owed under the service level agreement, and buyers should acknowledge it when they meet the account team.

What remains open. A cause stated in one sentence is not a review, and most of what a buyer needs in order to act remains outstanding. Microsoft’s documentation commits it to a preliminary post-incident review “within 48 hours of incident resolution” and a final review “within five business days,” delivered through each tenant’s Service health page. Charles Lamanna said on November 13, “We will publish the post-mortem shortly covering the step-by-step timeline and our many repair items to avoid similar outages in the future.” No review had been published at 03:28 UTC on November 15. The incident record’s last update promises “a preliminary Post-Incident Report within two business days” and “a final Post-Incident Report within five business days.”

The four tests. Four tests will decide whether that review is useful. The upgrade and the later change should be identified and dated. So should the safeguard that was meant to catch the fault, with the reason it did not. Buyers also need to know why the first statement found no correlated change. Last, the review should show that the same fault cannot recur across the rest of the fleet.

Six began with Microsoft’s own change. Microsoft’s account points to a change it made in six of the ten. The January 2023 incident began while “a network engineer was performing an operational task to add network capacity.” During July 2024, “a backend cluster management workflow deployed a configuration change causing backend access to be blocked.” For November 2024 the company cited “a change that caused an influx of retry requests.” July 2026 ended when it finished reverting a networking update, and the three-day incident that began on August 31, 2026 was put down to “core authentication configuration issues.” This week’s incident, on Microsoft’s statement of November 13, traces to “an issue during an earlier network capacity upgrade,” the second time in this record that work on network capacity is named.

Two began outside and were completed inside. Two more started outside Microsoft and were turned into outages by its own configuration. On July 30, 2024 a denial-of-service attack was, in Microsoft’s words, “merely a trigger event,” and “an unrelated latent network configuration issue” did the damage. The October 29, 2025 incident began when a valid sequence of customer changes “exposed a latent bug in the data plane,” and Microsoft recorded that “the configuration passed through the protection safeguards and propagated to later stages.” One incident, in June 2023, was an attack by a group Microsoft tracks as Storm-1359. Another, in January 2026, carries no stated cause in the record reviewed.

The count by year. The record thickens in 2026. Two of the ten incidents fall in 2023, three in 2024, one in 2025, and four in 2026, with the year not yet over. The longest stated length also belongs to this year, about 73 hours from August 31 to September 3. Greyhound Research draws a narrow conclusion from that. This record counts incidents that reached several services at once and is not a complete history, so it cannot show a trend in Microsoft’s reliability. What it gives a buyer is four dated events from one year to put on the table at renewal.

Three qualifications. Three qualifications keep the count honest. Microsoft publishes these reviews, and five of the ten rows rest on documents it chose to make public, which is more than most vendors offer. A provider that ships changes continuously will find change behind most of its failures, so the share alone is not an indictment. And Greyhound Research has not compiled the same record for any rival, so nothing here says Microsoft’s rate is worse than its peers’. The finding concerns the kind of risk a buyer holds, which is the vendor’s own change calendar.

The gate exists on paper. Microsoft documents a gate for exactly this. Its safe deployment practice states that “all code and configuration changes go through a lifecycle of specific stages,” with mandatory bake times between them, and concedes that “no configuration change is free of risk.” The Microsoft 365 change management page describes builds released through rings, and a documented rollback plan for changes that involve no code. That page does not say whether network configuration changes pass through the same rings, and the October 2025 review shows a safeguard that existed and was passed.

Who owns the calendar. This is the part of consolidation that buyers priced least. When the mail server sat in the company’s own data center, the company owned the change calendar and could freeze it before quarter end. On a shared platform the calendar belongs to the vendor, and the buyer usually learns of an infrastructure change when it fails. Regulators have noticed, and the UK rules that have applied to Microsoft’s designated entity since July 2026 carry a requirement headed “Change management,” which moves the gate from engineering culture to supervision.

The controls were inside the radius. By 21:41 UTC on November 12, Microsoft’s list of affected services included Intune, Defender for Office 365, and Purview, alongside the Defender portal it had flagged earlier. Device management, mail protection, and data governance were degraded inside the incident they would normally be used to manage. The admin center for Microsoft 365 Apps joined the list half an hour later. An administrator trying to see the state of the estate was looking through the estate.

The radius crossed the vendor boundary. Zoom’s status page recorded a “Service Degradation Affecting Microsoft Integrations due to an underlying vendor issue.” That entry was marked resolved at 09:12 UTC on November 14, about three hours after Microsoft’s statement. Anthropic said it had “identified an issue with an upstream provider affecting its Microsoft 365 connector,” and OpenAI said it was “investigating an issue with Microsoft connectors.” People who read Google-hosted mail through Outlook reported trouble reaching it. A second vendor reached through the first vendor’s client or connector is not a second path.

The AI layer raises the stakes. Greyhound Research argued in The Front Door Race that an assistant reaches enterprise systems through a door someone else controls. An outage is the availability form of the same point. As organizations hand approvals, summaries, and first drafts of decisions to assistants and agents that read mail, calendar, and files through one graph, a mail failure stops being a communications problem. It becomes a stoppage in whatever work those agents were carrying.

The alternative reading. One caution belongs here. Shared dependence explains why the work layer fell together, and it is consistent with the control services falling too. Microsoft has not said, however, that the security and management services failed for the same reason as mail. They may have separate causes that coincided, and the review will settle that. For planning purposes the distinction changes little, because the estate a buyer runs has now shown that it can lose both layers in one night.

Part of this is the customer’s setting. Safe Links policies carry an option, “Wait for URL scanning to complete before delivering the message,” which Microsoft recommends turning on. With it off, the documented behavior is, “If URL scanning can’t complete, deliver the message anyway.” A tenant therefore decides in advance whether mail waits for the scan or goes ahead without it. That decision is rarely recorded as one. A setting inherited from a preset remains a decision, and this outage is the first time many organizations will have had cause to look at theirs.

The documented cases. Microsoft’s documentation describes three cases, and they do not fail the same way. In mail flow, a tenant that has selected the wait option holds messages “until scanning is finished.” At the moment of a click in an Office desktop app, a scan that cannot complete leaves the link unprotected, and “the user is warned before they proceed to the destination website.” Where an app cannot read the policy at all, which the page illustrates with classic Outlook, “the user doesn’t receive Safe Links protection, and the user is redirected to the clicked link.” Only the first case keeps a dangerous link away from the user, and it applies only in tenants that chose it.

The wider gap. The scanning gap sat inside a larger one. Microsoft said users might be unable to load Defender portal pages, Intune device management might be unavailable to administrators, and Purview was on the affected list. Meanwhile the human attack surface widened. The UK’s National Cyber Security Centre said it was “recommending that everyone exercises caution around unexpected calls and messages,” and banks in Asia and Australia warned of scammers posing as technical support. A service desk flooded with sign-in complaints is where an impersonator asks for a password or multifactor reset.

What is not known. No public evidence shows that anyone exploited the gap, and Greyhound Research makes no such claim. Microsoft has said it has “no evidence of malicious activity associated with this incident.” The exposure is a window, bounded by the hours in which checks could not complete, and the work for a security team is to establish what passed through its own tenant in that window. That is a finite task with a known order, and some of the evidence expires.

Three decisions for the security chief. Three decisions belong to the chief information security officer and to no one else. Whether mail with links waits or flows when the scan cannot run is the first. What the service desk may reset, and on what proof, while the identity system is degraded is the second. Which controls the organization is prepared to run without, and for how long before it restricts the activity they protect, is the third. Each is a trade between safety and continuity, and each fits on one page written before the next incident.

Three states of preparation. The first organization has no fallback. Its approval request sits in a mailbox no one can open, the approver’s reminder is a Teams message that does not arrive, and the finance lead cannot find the supplier’s telephone number because it lives in a contact card. By morning the cut-off has passed. A second organization has a paper fallback that names a telephone approval, but nobody ever drilled it, and the list of approvers’ mobile numbers sits in a SharePoint file. Only the third drilled once, six months earlier, and keeps the list on paper and in a system outside the suite.

After the service returns. The differences compound once mail flows again. Reconstruction fills the following days for the first organization, along with explaining a late payment. Its neighbor approves by telephone at the second attempt, then finds it has no record that satisfies audit. Only the third pays on time and files a one-page log. None of the three could have restored the service a minute sooner. The gap between them was set months before the outage, by whether someone had been asked to write one page and rehearse it.

The general point. Scale the case and the shape of the cost appears. An enterprise does not have one such process. It has a short list that cannot wait a day: payments, payroll, clinical handover, dispatch, market disclosure, and customer safety notices. For each, the fallback is small and unglamorous, a telephone tree, a second channel, a printed contact list, an authority to act on a recorded call. Technology is not what most organizations are missing. The list, the owner, and the drill are.

What the agreement says. Australia’s agreement is public, and its terms are modest. The memorandum of understanding between the Commonwealth and Microsoft Corporation describes itself as “a non-binding framework for strategic cooperation.” Clause 2.5 is its only provision on outages, and it reads, “Work together to prioritise the recovery of Australia’s digital economy as soon as possible from significant technology outages or digital disruptions within the Microsoft Corporation ecosystem.” Either side can end the memorandum on 30 days’ written notice. It names no service level, no sequence, and no remedy.

The rest of the agreement. Outage recovery is one clause in a wider document. The government’s announcement in June 2026 gave the first areas of focus as “subsea cable security, hyperscale cloud resilience, secure use of artificial intelligence,” resilience for small businesses and critical infrastructure, and emerging cyber threats. In its clause on hyperscale infrastructure the parties “agree to collaborate on resilience exercises for government and/or industry” on that theme. The memorandum “becomes effective upon signature and will be reviewed annually.” Microsoft’s was the only agreement on the department’s page of digital resilience agreements when Greyhound Research read it. Other governments therefore have a public template to ask for, and an enterprise has a model of what to request in writing: a clause on recovery, a joint exercise, and an annual review.

What happened next. Events were consistent with priority and do not prove it. Microsoft reported traffic “being gradually restored” in Asia Pacific at about 11:00 UTC, which was 10 pm in Sydney, and reported “encouraging recovery progress in Europe” roughly an hour later. Asia Pacific came back first. One explanation is the agreement. The other is load, because a metered recovery starts where demand is lowest, and at that hour the working day had ended across most of Asia Pacific while Europe was at its desks. Microsoft has not said which applies, or whether customer identity plays any part in sequencing.

A queue exists either way. Either explanation leaves the same fact standing. When capacity returns in stages, something decides the stages. It may be geography, infrastructure dependency, or load, and it may also include who the customer is. A national government has now shown that it holds a clause and a contact for that moment. An enterprise on standard terms holds neither, and the Microsoft documents Greyhound Research read state no order of restoration. The same is true of every rival suite reviewed for this research note.

What an enterprise can ask. An enterprise cannot buy a place at the front, and Greyhound Research does not suggest that it try. What it can do is put three plain questions in writing and keep the answers. Does Microsoft sequence restoration by anything other than infrastructure and load? If governments or regulated sectors hold priority, which ones, and does the buyer’s sector qualify? When status notices go out, who receives them first, and by what channel? A refusal to answer is also an answer, and it belongs in the buyer’s risk register.

The view from government. Governments should read their own position with equal care. A non-binding clause that was invoked in public creates an expectation the text does not support, and other governments will now ask for the same words. If priority becomes something negotiated country by country, customers without a clause, which means most enterprises and smaller states, wait longer by construction. That is a question about fairness in shared infrastructure, and it is properly one for regulators and not for sales teams.

United Kingdom. The UK rules reach the provider directly. A designated critical third party must submit an incident report “as soon as is practicable” after an operational incident, “to the regulators and to affected firms.” Intermediate reports follow any significant change, and a final report is due within a reasonable time of resolution. The rulebook also requires scenario testing, an incident management playbook exercise with a sample of firms, and arrangements for orderly termination. Regulators were clear that the regime “complements, but does not replace” the duties of the firms themselves.

The perimeter question. One limit decides how far this reaches. The rules attach to a provider’s systemic third party services, and the public instruments do not list which of Microsoft’s services are treated as systemic. Whether a mail and collaboration suite sits inside that perimeter, as opposed to the infrastructure cloud beneath banks’ core systems, is not stated in any document Greyhound Research read. Inside the perimeter, UK financial firms were owed a report from Microsoft this week under rule, not courtesy. Outside it, the regime has a gap exactly where this outage struck.

European Union. The European regime works differently. A Lead Overseer can request information, conduct inspections, and issue recommendations, including on how updates are rolled out, while financial entities carry the reporting clock themselves. For a major incident the initial report is due within four hours of classification and no later than 24 hours from awareness. A bank whose classification procedure, escalation list, and regulator contacts lived in the suite that was down had to meet that clock without them.

Asia Pacific and the United States. Elsewhere the duty sits with the regulated firm. Australia’s prudential standard requires notice to the regulator within 24 hours of a disruption to a critical operation outside tolerance. Singapore’s notice to banks sets a recovery time objective of no more than four hours for each critical system, with notification within one hour of discovery. India’s central bank requires banks to assess concentration risk and to test continuity plans that include the exit of a service provider, and its securities regulator has reserved the power to set concentration limits on cloud providers. In the United States the interagency guidance is not binding, and a replacement proposed in September 2026 is open for comment until November 16.

India. India’s rules put the duty on the regulated firm and are specific about exit. The Reserve Bank’s 2025 directions for commercial banks require continuity plans “based on realistic and probable disruptive scenarios” that are tested periodically, and an outsourcing policy with “a clear exit strategy for ensuring business continuity during and after exit.” Existing IT outsourcing agreements had to comply at renewal or by April 10, 2026, whichever came first. The securities regulator’s cloud framework asks each regulated entity to assess “its exposure to CSP lock-in and concentration risks” (CSP means cloud service provider) and to hold “a viable and effective contingency plan” for a disruption or shutdown of cloud services. India’s rule on reporting within six hours covers cyber incidents of listed types, so whether it applies to an outage with no malicious cause is a question for counsel.

What regulators have said. Regulators have said little in public, and most of it concerns their own operations. The Bank of England said, “All critical operations at the Bank are running normally.” Britain’s medicines regulator said its “public safety responsibilities continue uninterrupted” during the outage. Reports said the Financial Conduct Authority was aware of the outage and monitoring it. In the reports Greyhound Research read to the cutoff, no regulator had said that it had asked Microsoft for a report or opened a review. Where the UK rules apply, an incident report goes to the regulators and to affected firms, so silence in public does not show that nothing is happening.

Everyone else. Set against that map, the unregulated enterprise stands out. A manufacturer, a retailer, a hospital group outside a financial regime, or a mid-sized services firm has no supervisor asking Microsoft for a report, no statutory right to be told, and no rule that forces an exit plan into existence. It holds the standard contract and whatever it thought to write down. Regulated sectors did not win their protections by negotiating. They received them because a supervisor decided the dependence was systemic, and that reasoning applies with equal force outside finance.

The edition read. Greyhound Research read the edition dated October 1, 2026, which Microsoft’s licensing site lists as current. It is the standard text. Enterprise customers should confirm each term against the agreement attached to their own contract, because a negotiated amendment would not appear in it.

The arithmetic. The arithmetic is short. In a 30-day month, 99.9 percent allows 43.2 minutes of downtime, 99 percent allows 7.2 hours, and 95 percent allows 36 hours, on the simplifying assumption that every user is down for the whole period. Uptime is counted in user-minutes, so an outage that reaches some users for some of the time counts for less than its clock length. An organization whose mail was unavailable to everyone for 26 hours in November, from the first mailbox failures to Microsoft’s report of broad recovery, would sit in the 50 percent tier, and its remedy would be half of one month’s fee for Exchange Online.

How downtime is defined. The definitions decide the count before any arithmetic begins. For Exchange Online the agreement defines downtime as “Any period of time when users are unable to send or receive email with Outlook Web Access,” and for Teams as any period when end users “are unable to conduct instant messaging conversations or initiate online meetings.” Downtime is then “the sum of the length (in minutes) of each Incident” multiplied by “the number of users impacted by that Incident.” Greyhound Research reads two consequences into that wording, which counsel should confirm. The mail definition is tied to the browser client, so a user whose desktop client failed while the browser mailbox still opened may not count. And the number of users affected has to be shown by the customer, which makes a record kept during the outage worth more than one rebuilt afterwards.

The claim. Nothing arrives unless it is claimed. A customer must submit a claim to Microsoft support with a description of the incident and the time and duration of downtime, and for Microsoft 365 the claim must arrive by the end of the month after the one in which the incident occurred. For this incident that means December 31, 2026. Customers that buy through a partner depend on the partner to file. Microsoft’s training material puts it plainly: “Your organization is responsible for submitting a claim on an incident.”

The claim file. The agreement lists what a claim must hold: “a detailed description of the Incident,” the time and duration of downtime, the affected resource names, “the number and location(s) of affected users,” and a description of the errors that occurred. Leave any of it out and the agreement says the claim will be rejected. Microsoft says it processes claims “typically within forty-five (45) days of receipt of the claim.” Where one incident breaches more than one service level for the same service, the customer “must choose only one Service Level under which to make a claim.” A customer that buys through a partner cannot file for itself. Microsoft’s partner rules accept credit requests “only from CSP direct and indirect providers” and ask for the tenant ID, the outage ID from the Service Health Dashboard, and an email from the affected tenant’s own domain.

What a credit measures. A credit measures the vendor’s bad day, not the customer’s. It is indexed to the license fee for the affected service and to nothing the outage cost: the missed cut-off, the idle contact center, the overtime, and the regulatory report. The agreement says so in terms: credits “will not be awarded to compensate for any other forms of loss, including but not limited to lost revenue, operational costs, or any indirect losses.” For most enterprises a month of mail licenses is a small sum beside one hour of a stopped process. That is not a criticism peculiar to Microsoft. Google’s agreement pays in days of service, capped at fifteen, and none of the suites reviewed for this research note prices consequential loss into its standard terms.

The monthly clock. The second weakness is the clock, because each month starts clean. Microsoft’s agreement defines the period for a credit as “the calendar month in which a Service Credit is owed,” so four incidents in different months are separate events, each measured against its own allowance and each needing its own claim. Nothing in the edition read looks across months, and nothing gives a customer a right to terminate or reprice when breaches repeat. Microsoft does publish a longer view. Its quarterly uptime table shows 99.526 percent for the first quarter of 2026, which Greyhound Research converts to about 10.2 hours across all users in a 90-day quarter.

The fair reading. The fair reading has two sides. Publishing a quarterly figure that shows a poor quarter is to Microsoft’s credit, and its written terms are fuller than any rival’s. The instrument was nonetheless designed for isolated lapses, and 2026 has not been a year of isolated lapses. Finance leaders should treat credits as a small, certain recovery to be collected on time, and should stop treating them as the protection. Protection sits elsewhere, in what the organization has rehearsed and in what it has negotiated beyond the standard form.

Method. The method follows the one Greyhound Research used for the Five Terms in its research on Oracle’s multicloud contracts: read the vendor’s own legal and documentation pages, quote what is there, and mark as not stated what is not, bounded to the documents named. Five suites are covered: Microsoft 365, Google Workspace, Slack, Zoom Workplace, and Salesforce, the last read only in part. Twelve criteria cover the availability commitment, credits, the claim process, the measurement window, post-incident reports, status channels outside the service, published uptime, change safety, scanning behavior on failure, order of restoration, escalation, and exit.

Limits. The scorecard has limits that readers should hold onto. It reads public documents as they stood on November 14, 2026, and enterprise customers may hold negotiated terms that differ. Microsoft’s grades rest on the October 2026 edition of its agreement. Salesforce is included because Slack now takes its support terms from Salesforce, and three of its cells were not checked. A grade of written says the vendor committed to something on paper. Whether the commitment is generous is a separate judgment.

Who has written most. Microsoft has the most in writing, by a distance. Nine of its twelve cells are written, two partly, and one not stated. Google Workspace follows with six written, two partly, and four not stated, and its public agreement is the clearest single document in the set. Slack’s current agreement promises “commercially reasonable efforts” with no percentage and no credits, a retreat from the 99.99 percent it published in 2015. Zoom publishes no service level agreement of its own, and the only availability terms found were those of a reseller.

Where rivals lead. Rivals lead on a few cells, and those cells matter. Google’s status dashboard is public, carries up to five years of history, and has in practice carried preliminary and final incident reports that anyone can read, where Microsoft’s reviews arrive inside the tenant. Zoom’s status page offers text message and webhook subscriptions, and Zoom’s support plans state restore targets, which Microsoft’s public documents do not. Google is also candid about a weakness Microsoft shares: “If Gmail is affected, email alerts may be delayed.”

The empty row. One row is empty for every vendor. None of the five states an order of restoration. Not one says whether recovery is sequenced by region, by infrastructure, by sector, or by customer, and none says who is notified first. The question Australia raised in public has no written answer anywhere in this market. That turns a Microsoft finding into a market finding, and it is the strongest argument that switching suites does not address the problem this outage exposed.

The destinations. The destination is no simpler. Google’s organization-wide export “typically takes 72 hours but can take up to 14 days,” needs a support request for organizations of more than 1,000 users, and is unavailable once a subscription is canceled or suspended. Slack exports of private channels and direct messages need an application and the primary owner’s approval. Zoom allows thirty days to retrieve content after termination. Each of these is a migration planned over months, and none helps an organization whose mail is down this afternoon.

Two exits. Two different things travel under the word exit. One is leaving for good, a program that rules in the European Union and supervisory expectations in the United Kingdom already ask financial firms to plan and test for critical services. The other is leaving for a day, which is the capacity to run a short list of processes without the suite and return when it recovers. This outage showed how the client can undermine the first, since people who read Google-hosted mail through Outlook had trouble reaching it. It also showed that the second is what most organizations lack.

Why not a second suite. Greyhound Research does not recommend a second suite held in reserve. Dual running doubles license and administration cost, splits identity and data governance, and widens the surface the security team must watch, all to cover a few days a year. The better investment is narrow: an independent channel for crisis communication, an emergency mail route for a small group, contact data held outside the tenant, and offline copies of the handful of documents the business cannot work without. Those cost little, and they are what the regulated standard calls contingency.

What Greyhound Research accepts. Greyhound Research accepts most of that, and the thesis of this research note was built to survive it. Nothing here argues for leaving, for a second suite, or for treating Microsoft as an unreliable supplier. The uptime figures are real, and the comparison with rivals favors Microsoft. A panicked response would indeed cost more than the outages do. Where the objection fails is on a single clause: that because concentration is the right strategy, the standard terms around it are adequate.

Where it fails. Three things in the evidence break that clause. An average hides shape, because a quarter at 99.5 percent can be one long night in which the control layer was dark, and no average records what was unavailable together. Tolerance is set process by process, and a day is intolerable for a payment run or a clinical handover even when it is trivial for a slide deck. Regulators, finally, are acting for finance in a handful of jurisdictions, which leaves most of the economy on the standard form.

The size of the remedy. The remedy proposed here is also small beside the objection’s fear. A fallback list, a drill, a recorded decision on security defaults, an evidence routine, and a set of questions at renewal cost weeks of staff time and no new platform. The objection imagines a choice between consolidation and resilience. Having both is what the evidence supports, with the second bought cheaply because the first was bought well.

Save the service health entries for TM1550488, EX1550543, and MO1550821, with every update, and record which processes stopped and for how long while memories are fresh. The admin center keeps incident history for 30 days, and the review will be delivered into the same place. This file is the base for the claim, the board paper, and the renewal. Rests on: Microsoft’s service health documentation. When: First week.

Claims for Microsoft 365 must reach Microsoft by the end of the month after the incident, which is December 31, 2026, with a description of the incident and the time and duration of downtime. Organizations that buy through a partner should obtain written confirmation that the partner has filed. Treat the credit as a receivable with a deadline. Rests on: The service level agreement and Partner Center guidance. When: By December 31, 2026.

Agree the short list with the business, not inside IT. For each process, write the route it takes when mail, Teams, and SharePoint are unavailable: a telephone tree, an alternate channel, an offline copy of the documents it needs. Each route must avoid the suite’s sign-in as well as its services. Rests on: The dependency reading and the payment case. When: Within thirty days of resolution.

Microsoft’s documentation allows two email addresses per administrator for service health alerts and does not say where they should sit. Point them outside the tenant, follow the public status page and status account, and stand up a channel for reaching staff that does not use the suite’s identity. Keep the contact list where it can be read when the suite cannot. Rests on: Microsoft’s service health documentation. When: Within thirty days of resolution.

Ask in writing how restoration is sequenced, whether reviews can be delivered outside the tenant, and what follows when monthly commitments are missed repeatedly. Record the answers and the refusals. A renewal is the one moment a standard agreement is open to amendment, and the questions cost nothing to ask. Rests on: The Greyhound Outage Terms Scorecard. When: Before the next renewal.

Establish the hours in which Safe Links and other checks could not complete for the tenant, then pull the messages delivered, the links clicked, the sign-ins accepted, and the resets performed in those hours. Most organizations will find nothing. Write the finding down either way. Rests on: Microsoft’s Safe Links documentation. When: First week.

Check whether the policy waits for URL scanning before delivery, which Microsoft recommends, or delivers anyway. Either choice is defensible. Holding mail guards against a malicious link and delays business during an incident, so the choice should carry an owner’s name and a date. Rests on: Microsoft’s Safe Links documentation. When: First week.

During an incident and for a set period after it, allow no password or multifactor reset without verification through a second channel the caller did not supply. Tell staff that support will never ask for credentials by telephone or message. Fraud attempts follow outages closely, and the desk is the usual door. Rests on: Warnings issued during the outage. When: First week.

List each control that depends on a cloud service, including mail protection, device compliance, conditional access, and data loss prevention. For each, record what it does when it cannot complete its check, who accepted that, and how long the organization will run in that state before restricting the activity. Rests on: The security reading. When: Within thirty days of resolution.

Most continuity exercises assume the security consoles are available. Run one in which mail, Teams, the admin center, and the Defender portal are all unreachable, with the business in the room. The aim is to find the decisions nobody is authorized to make in that state. Rests on: The affected-services record. When: Before the next renewal.

Every other move in this Runbook rests on this list, and few organizations hold one the business has agreed. Technology teams keep a list of critical systems, which is a different thing. Ask each business head for the processes whose failure for one working day would harm a customer, breach a rule, or lose money that cannot be recovered, then cut the merged list hard. Without it, continuity spending is spread across everything and protects nothing in particular. The decision sits with the chief executive, on the chief operating officer’s recommendation.

A fallback without an owner is only a document. The page states who invokes the fallback, the alternate route, the contacts, and the authority to act. It should be short enough to read on a telephone and complete enough to follow at night. The decision sits with each business unit head.

A fallback that has never been used fails on details: a number that changed, a sign-in that depends on the suite, a form nobody can find. One rehearsal a year finds most of them. Rehearsals that leave mail running find none. The decision sits with the chief operating officer.

Regulated firms already set tolerances because their supervisors require it. The discipline is worth borrowing everywhere. A stated tolerance turns an outage from a surprise into a trigger, and it tells the people on duty when to stop waiting for the vendor and invoke the fallback. The decision sits with the chief risk officer.

Emergency authority improvised during an incident is how fraud succeeds. Agree beforehand which payments and commitments can be approved outside the normal system, by whom, up to what limit, and with what call-back check. Then the fallback for a payment is a procedure and not a favor. The decision sits with the chief financial officer.

The credit is small and certain. What the outage cost is larger, and it stays unmeasured unless finance asks each business head for it. Present both figures together once, so that the board sees the ratio and stops regarding the agreement as cover. The decision sits with the chief financial officer.

An outage starts several clocks at once: the claim window, any duty to notify customers under contract, and any duty to report to a regulator. Different teams own them, and none can see the others. One calendar, held by legal, prevents the quiet lapse. The decision sits with the general counsel.

People improvise with personal accounts when no route is given, and information leaves governed systems. A short standing instruction, issued in calm conditions and repeated at onboarding, removes most of that. It names the channel, the rule on personal accounts, and whom to call. The decision sits with the chief people officer.

A holding statement drafted in advance, with the channels it will go out on and the person who can release it, turns hours of drafting into minutes. Customers forgive an outage that was explained faster than they forgive silence. The decision sits with the chief communications officer.

A board that hears about its productivity suite only after an outage is governing by incident. One annual paper is enough. It should carry the list, the drills run, the questions put to the vendor, and the answers received. The decision sits with the board chair and the chair of the risk committee.

Deliver the preliminary and final post-incident reviews to named contacts by a channel that does not depend on the affected service, within the times Microsoft already publishes. The lever. Any customer can ask. UK financial firms can point to the rule on reports to affected firms, if the service is inside its perimeter. The likely concession. Little. Microsoft may tie it to a paid support plan. If the answer is no. Assign an administrator to export the review from Service health as soon as it appears.

Notify named contacts at addresses and numbers outside the tenant when an incident is declared and at each status change. The lever. The documentation already allows two addresses per administrator and does not restrict where they sit. The likely concession. None for email. Text or voice alerts may sit behind a support plan. If the answer is no. Subscribe independently to the public status page and status account, and test the route.

State in writing whether restoration is sequenced by anything other than infrastructure and load, and whether any class of customer holds priority. The lever. Any customer can ask the question. Public bodies and critical infrastructure operators have the strongest standing. The likely concession. None for disclosure. Priority itself would carry a price. If the answer is no. Record the refusal in the risk register and raise it through the regulator or the sector body.

Provide, once a year, evidence that configuration changes to shared network and identity layers follow staged rollout, with exceptions reported. The lever. Regulated firms can cite contract requirements on service levels and the UK requirement on change management. The likely concession. Disclosure under confidentiality, probably through existing assurance reports. If the answer is no. Ask which assurance report covers change management, and read that section.

Where a service misses its monthly commitment in more than an agreed number of months in a rolling year, allow termination of that service without penalty or repricing at renewal. The lever. Large customers at renewal only. The likely concession. A longer term or a larger commitment. If the answer is no. Keep the rolling record yourself and bring it to the pricing discussion.

Apply the credit automatically when Microsoft’s own service health record shows the threshold was missed. The lever. Large customers, and partners acting together. The likely concession. Unlikely to be granted alone. Expect it to be traded against term. If the answer is no. Make the claim a standing finance procedure with a named owner.

Document, for each security and compliance control, what it does when it cannot complete a check, and notify customers when that behavior changes. The lever. Any customer can ask. Safe Links is already documented this way, which sets the precedent. The likely concession. None. If the answer is no. Test each control’s behavior yourself and record the result in the fail-state register.

Commit to a transition period and export support beyond the 90-day retention window, with a stated rate of extraction. The lever. Regulated firms can cite the European requirement for a mandatory transition period. The likely concession. A paid service. If the answer is no. Test the export once a year on a sample, and time it.

A board cannot judge the dependence from a description of the vendor’s fault. It needs the organization’s own account, process by process. Ask to see. An impact log by process, with hours lost.

A plan that exists and a plan that works look identical on paper. The date of the last drill separates them. Ask to see. The drill record for each process.

The answer shows whether fail-open and fail-closed choices are owned by an executive or inherited from a default. Ask to see. The fail-state register and the review of the window.

If the answer is the news or social media, the organization’s crisis information depends on the system in crisis. Ask to see. A tested alert route that sits outside the suite.

Questions put informally leave no record. The file of questions and answers is the organization’s position at the next renewal. Ask to see. The correspondence log.

Reporting clocks start when the organization becomes aware, not when the vendor explains. Ask to see. The reportability decision, timed and signed.

A strategy with no stated conditions for review is held by habit. Naming the conditions keeps the decision deliberate. Ask to see. Named triggers and a named owner.

India time. The clock was unkind to the subcontinent. Mailbox failures began at 16:17 UTC, which is 21:47 in India, and users there began flagging problems around 11 pm on Thursday. Recovery reached Asia Pacific at about 11:00 UTC on Friday, 16:30 in India, so the outage covered almost the whole of a delivery center’s Friday. IndiGo said its email support services were impacted, and Akasa Air reported delays. Air India said its flight operations were unaffected and that it had implemented temporary email rerouting, which is what a working fallback looks like from outside.

As operator. The firm’s exposure runs through its service desk. A managed client’s users call the desk when they cannot sign in, the desk’s own tools sit on the same platform, and the queue becomes cover for anyone impersonating a user to obtain a reset. Contracts between services firms and clients are private, so Greyhound Research cannot say how they allocate a platform outage. The practical position is visible all the same. A client’s first call goes to the provider, whatever the contract says about whose fault it is.

As claimant. The firm works to Microsoft’s rules. Partner Center guidance says credit requests are accepted only from direct and indirect providers in the Cloud Solution Provider program, and must arrive within one month from the end of the billing month in which the incident occurred. Each request must carry the tenant ID, the outage ID, and a customer email sent from the domain of the affected tenant. For a provider that manages hundreds of tenants, that is hundreds of separate evidence files, each waiting on a client who must write in once the service that carries the email is restored.

Who carries the cost. The costs land unevenly. Microsoft’s liability is capped at a credit against license fees. Each client carries its own loss. Between them, the provider absorbs the service desk surge, the hours spent assembling claims, and the commercial conversation with a client who sees one supplier, not two. Providers that sell continuity as part of a managed service now have a product to build: an out-of-band channel, a client communication written once in advance, and a claims process that runs without being asked.

Said so far. The incident “was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change.” Neither the upgrade nor the change is identified. The answer settles. Whether the review confirms this incident as the sixth that began with Microsoft’s own change. Evidence that would settle it. Microsoft’s post-incident review, naming the upgrade, the later change, and their change records. Greyhound Research would update. The counts in Exhibit 3 and Table 2.

Said so far. Not stated. The answer settles. Whether change records and telemetry are reconciled while an incident is live. Evidence that would settle it. The review’s timeline, showing when the change was deployed and when it was first examined. Greyhound Research would update. The reading of the change gate.

Said so far. Not stated. The answer settles. Whether staged rollout covers network and identity configuration. Evidence that would settle it. A description of the rollout stages the change passed through, and the stage that should have stopped it. Greyhound Research would update. Microsoft’s grade on change safety in the scorecard.

Said so far. Not stated. The services appeared on the affected list. The answer settles. Whether the control layer shares the work layer’s failure, or only coincided with it. Evidence that would settle it. The review’s root cause for each affected service, service by service. Greyhound Research would update. The blast radius reading and Exhibit 4.

Said so far. Not stated. The answer settles. The size of the incident, which no public figure establishes. Evidence that would settle it. A count or share of affected tenants or infrastructure, by region, in the review. Greyhound Research would update. The sizing statements in the opening section.

Said so far. Not stated. The answer settles. Whether customer identity plays any part in sequencing. Evidence that would settle it. A written statement of the sequencing policy, from Microsoft or from Australia’s Department of Home Affairs. Greyhound Research would update. The restoration order reading, Table 4, and the scorecard’s empty row.

Said so far. Not stated by Microsoft or by any regulator. The answer settles. Whether the new regimes reach a productivity suite in practice. Evidence that would settle it. A statement from Microsoft, a UK financial regulator, or a European supervisor that a report was made. Greyhound Research would update. Table 5 and the perimeter question.

Said so far. Documentation says reviews are delivered through each tenant’s Service health. An executive said Microsoft “will publish the post-mortem shortly.” The incident record promises a preliminary report “within two business days.” The answer settles. Whether partners, auditors, and the public can read the account. Evidence that would settle it. Publication of the review on a public Microsoft page, as Azure does for its broadest incidents. Greyhound Research would update. Microsoft’s grade on post-incident reports.

Said so far. Safe Links “may be unable to verify URLs.” No times are given. The answer settles. The window each security team must review. Evidence that would settle it. Start and end times for degraded scanning, in the review or in each tenant’s Service health record. Greyhound Research would update. Table 3 and the security reading.

Said so far. Not stated. The answer settles. Whether repetition carries any consequence beyond separate monthly credits. Evidence that would settle it. A change to the standard agreement, or a written commitment to affected customers. Greyhound Research would update. The Negotiation Lens term on repeated breach.