The proof of the outage has to come from the mailbox that was down

As we write this, the Microsoft 365 outage that started yesterday afternoon is still open with no ETA for recovery. There are a hundred write-ups of that already. Let us go to the money: this gets paid for. The service level agreement provides for a credit, but it is not paid automatically, it is not computed off the newsroom clock and —if you bought your Microsoft 365 through a third party, as most Spanish SMEs do— you are not the one who asks for it. And the evidence Microsoft requires in order to pay has to reach it in an email sent from the domain of the affected tenant. That is: from the mailbox that was down.

Where things stand at eight in the morning

Two identifiers, which are the ones that matter for everything else: EX1550543 for Exchange Online and MO1550821 for the rest of the suite. It began on Thursday 12 in the afternoon, European time, with users unable to connect to their mailboxes "through multiple connection methods" in the Americas, and it spread. Microsoft's status page has been listing Exchange Online, Teams, SharePoint Online, Copilot, Defender, Planner, To Do, Intune, Purview and Power BI. Microsoft has written that there is no indication of malicious activity, and that it is still investigating what triggered the failures.

Three sentences from Microsoft's updates are worth keeping. The first is a correction of itself: it determined that the elevated load was not driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable and failing automated health checks. The second describes why this is dragging on, and this one is a direct quote: "the servers we returned to service can become unresponsive again once they receive traffic". The third explains what you are seeing: Microsoft is temporarily restricting, in some locations, which types of traffic can reach the affected infrastructure. Hence access being intermittent even in regions listed as recovered. At 04:10 GMT today it reported partial recovery in some regions and added that those actions were not resulting in sustained recovery.

The two technical readings this usually calls for are already published and we are not repeating them: why a list of services down at once is a shared-dependency map handed to you for free, and why a machine that returns to service and falls over when traffic hits it is a start-up problem rather than a restore problem. Today we go somewhere else, because one part of this outage has an expiry date.

The credit is a percentage of your fee, not compensation

For Exchange Online, the consolidated SLA for online services commits to 99.9% monthly and settles breaches as a credit against the fee for that service. There are three tiers: below 99.9%, 25%; below 99%, 50%; below 95%, 100%. The monthly uptime percentage is not about hours, it is about people: ((User Minutes − Downtime) / User Minutes) × 100, where downtime is the sum, incident by incident, of the minutes it lasted multiplied by the number of users it hit.

Let us do this month's arithmetic. November has 30 days: 43,200 minutes per user. On that basis, the three SLA thresholds land like this:

Look at the middle row, because that is the detail that decides whether an hour of paperwork is worth it: the jump from 25% to 50% sits at 7 hours and 12 minutes. An outage that starts mid-afternoon and runs past midnight lands right on that threshold. And the per-user split cuts both ways: if only half your staff lost their mailbox, your downtime user-minutes halve and the month never drops below 99% even though the incident lasted exactly as long. There is no universal percentage for this outage. There is yours, and it comes out of your headcount and your clock.

Two clarifications before anyone makes plans. First: the credit is computed service by service, and Microsoft illustrates it with its own example —if the customer has an Office 365 suite but only suffered a SharePoint outage, the SLA credit is approved for SharePoint and not for the customer's entire plan. Second: a credit never exceeds the monthly fee for that service, and the agreement itself says it is not awarded to compensate for any other form of loss, including lost revenue. It is a discount on your Microsoft bill. The arithmetic of why an availability percentage tells you nothing about how long a single outage lasts we already took apart in October.

What counts as downtime is defined on Outlook Web Access

We already covered this piece of small print in August with a different incident —there are breakdowns that stop your office and that the SLA does not count as downtime— so here it goes short. The agreement defines Exchange Online downtime as "any period of time when users are unable to send or receive email with Outlook Web Access", the old name for Outlook on the web. It does not say the desktop client, or the phone. This time Microsoft's advisory spoke of mailboxes unreachable "through multiple connection methods", so the web is inside the computation.

The evidence has to come out of the mailbox that was down

Microsoft's documentation for CSP program providers spells out what has to be supplied, and that is where the detail in the headline lives. Verbatim: "Provide evidence that the outage affected the customer and that they requested SLA credit. Customer tenant ID and outage ID (from the Service Health Dashboard) must be provided. The customer email submitted as evidence must come from the domain of the affected tenant. (Email from a personal address isn't acceptable)".

Read it again with Thursday afternoon in mind. The credit request for a corporate email outage has to travel over the corporate email. If your people, mailbox dead, wrote from their usual Gmail —which is exactly what everybody does during an outage— that evidence does not count. It is not a trap or a mean trick: it is a fairly reasonable ownership check from Microsoft's side. But it requires somebody to remember to send that email from the domain, as soon as the service gives you a window, and before the calendar shuts the door.

And the email alone is not enough. The same page warns that "customer name, tenant identifier, partner ticket number, and ticket created date and time stamp aren't sufficient for a claim to process", and lists what does prove impact: information regarding the time and duration of the downtime; the number and locations of affected users "if applicable"; descriptions of your attempts to resolve the incident at the time of occurrence; an email from the affected customer requesting support and then applying credit; and the support ticket number with the details of customer contact.

We underline the third one because it is the one you cannot manufacture afterwards. "At the time of occurrence": what you tried, at what time, with what result. If nobody wrote anything down while it was happening, that field gets filled in from memory two weeks later, and from memory every outage lasted "all afternoon". The other four items can be pulled out of a system whenever you need them. This one has to be written on the day.

If you bought through a third party, you are not the one who claims

This is the part that throws almost everybody, and it is a single sentence: "credit requests are accepted only from CSP direct and indirect providers. Requests aren't accepted from indirect resellers". If your Microsoft 365 is contracted through the IT firm on the industrial estate —which is half of Spain— that firm may well be an indirect reseller, and then Microsoft will not take the claim from them either: it has to be escalated by their distributor, the indirect provider above them.

So the real chain for this outage has three hops: you write to whoever invoices you, whoever invoices you writes to their distributor if they cannot file it themselves, and the distributor opens the Partner Center ticket with your evidence inside. At every hop the incident ID, the tenant GUID or —above all— the email that had to come from your domain can go missing. We do not sell anybody's licences, so in this chain we are not the one invoicing you: we are the one documenting the incident and chasing the claim up with everything inside. Somebody else's paperwork is not an acceptable excuse when a calendar sets the deadline.

The deadline: 31 December

The agreement itself settles it with an example that leaves no room for interpretation: the claim must reach Microsoft "by the end of the Applicable Period following the month in which the Incident occurred", illustrated like this —if the Incident occurred on February 15th, the claim must be received by March 31st. Applied here: incident on 12 November, door shut on 31 December 2026. The channel documentation says the same thing in different words —two months from the end of the billing month for Azure, one month for all other services. The route for direct customers is the admin center, under Support, opening a new service request and asking for an SLA service credit with the incident identifier inside. Past the date there is no appeal: it is not that they turn you down, it is that the claim no longer exists.

The outage notebook: six fields, today

This is what we do while a provider is down, and there is nothing sophisticated about it. It is a shared document, opened in minute one, with six fields. It is written by whoever is on call, not by whoever files the claim later:

1. Your start time and your recovery time, on your own clock. In a claim what counts is when you saw it; the hour the vendor acknowledges it is usually a good deal later.
2. How many people and where. Number and locations. The source asks for it "if applicable", and it is applicable whenever you can count it. "The whole company" is not a number.
3. What was tried, with timestamps. Desktop Outlook, Outlook on the web, mobile, another network, another browser, re-signing in. This is the list you cannot rebuild afterwards.
4. The incident identifier and the tenant GUID, copied from your own admin center. The two-letter prefix names the service: EX Exchange Online, SP SharePoint, MO portal. Here: EX1550543 and MO1550821.
5. The incident history, exported, not linked. Service health updates get reworded while the incident is alive and end up archived; today's PDF or screenshot is your dated copy.
6. The request email, sent from an address in your own domain, asking for support and for the credit, with both identifiers inside. It is the field that expires and the only one that depends on the service giving you a window.

Six fields, a quarter of an hour spread across the incident. And a side effect worth more than the credit: that same notebook is the report the board will ask you for on Monday, and it is the basis of the conversation about which alternative channel your company has when email is gone. We build it into managed support precisely because in a provider outage there is nothing to fix: you only have to decide what stops, warn people over a channel that is still alive, and write down what happened.

When it is not worth it

If you are ten people on a basic plan, do the arithmetic before you start: 25% of one month of a single service for ten licences is a figure that does not even pay for the hour of whoever fills in the form. Saying it like that costs us work, but it is the truth. And there is a worse mistake than not claiming, which is letting the paperwork eat the response: if you have to choose between documenting the outage and opening the alternative channel so people can keep working, you open the channel. The notebook survives being written fifteen minutes late without losing anything.

The opposite case is the one we run into more often, and it is what really justifies the six fields: if your company has its own service level agreement signed with its customers —every software company does— yesterday you were not only the victim of somebody else's outage. You were also somebody's provider, and that somebody is going to ask you in writing what happened, how many of their users were locked out and what you did while it was going on. All three answers live in the same notebook. The difference between having it and not having it is not Microsoft's credit: it is whether your version of yesterday has timestamps or adjectives.

Nobody builds continuity on top of a discount, and the alternative channel and the list of what stops when email is gone are worked on before the next outage, not during it. But of everything yesterday afternoon left behind, this is the only piece with a number, an owner and an expiry date. If we manage your Microsoft 365, the notebook is part of the service and the request goes out with both identifiers inside. If not, the email to send starts with "I am requesting the SLA service credit for incidents EX1550543 and MO1550821", comes from an address in your own domain, and has until 31 December.

Sources (verified 13 Nov 2026, 08:00 CET). Microsoft Learn, "Request a credit from Microsoft - Partner Center": the sentence stating that credit requests are accepted only from CSP direct and indirect providers and not from indirect resellers; the deadlines (two months for Azure, one month for everything else from the end of the billing month); the required-information list and the impact-evidence list; the requirement that the customer email come from the domain of the affected tenant and that a personal address is not acceptable; the warning that name, GUID and ticket number are not sufficient; the example of a suite with a SharePoint-only outage; the note on advisory incidents and on a dashboard entry meaning a tenant might be affected; and the two-letter prefix table. Microsoft's consolidated SLA for online services (Worldwide English edition of 1 Jan 2026, read in the PDF): 99.9% monthly for Exchange Online, the uptime-percentage formula over user minutes, the downtime definition as "any period of time when users are unable to send or receive email with Outlook Web Access", the 25/50/100% credit tiers, the cap at the monthly service fee together with the clause stating credits do not compensate any other form of loss including lost revenue, and the claim-deadline rule with its own worked example (Incident on February 15th, claim by March 31st). Updates on incident EX1550543 / MO1550821 published by Microsoft in the admin center and on its public status page, as reported on 12 and 13 November by SecurityWeek and the trade press (the three quoted sentences, the list of affected services, the ruling out of an attack and the 04:10 GMT status). The reading of the resale chain and the six notebook fields are ours. Honest note: the percentage each tenant is owed depends on its own user-minute computation, which Microsoft performs using its own definition of downtime; none of the above guarantees any particular credit.