Some people have not been able to search in Microsoft 365 since Monday. For the SLA, that is not downtime

Since Monday 17 August, people have been typing a word into the search box in Outlook, SharePoint Online or OneDrive and getting nothing back. The notice sits in the Microsoft 365 message centre under the identifier MO1456424, and the last update we could read set the next review for this Friday at 04:00 UTC. Meanwhile that file still opens if you know where it is, and that email still sends and arrives. Which is the detail worth stopping on: under the definitions of downtime used by Microsoft's own contract, none of this happened.

What the advisory says, word for word

The title of the advisory is so literal it barely needs translating: "Some users may be unable to search for content in SharePoint Online, OneDrive, Outlook on the web, or Outlook desktop." The scope is carefully bounded: "Impact is specific to some users served through the affected infrastructure who are attempting to search for content in SharePoint Online, OneDrive, Outlook on the web, or Outlook desktop." Read it slowly, because it matters for what comes next: this does not hit every tenant, and it depends on which slice of Microsoft's infrastructure your mailbox sits on.

The cause Microsoft gives fits on one line: "A recent deployment introduced a resource utilization inefficiency issue, leading to impact." One of their own rollouts left the systems that index and retrieve content eating more resources than they should. No attacker, no third party, nothing to patch on your side, and credit where it is due: Microsoft says so plainly, without dressing it up as "unusual activity." It is the kind of fault you would have fixed in your own data centre by rolling the change back in twenty minutes, and that here gets fixed when your cluster comes up in the queue for the fix. What follows is not about the notice, which is well written. It is about what happens to it afterwards.

Read, write, send, receive: search is not on the list

Microsoft's online services SLA does not promise "that the service works." It promises a monthly uptime percentage, and to calculate it, it defines service by service what counts as Downtime. The three that appear in the advisory are worth reading, in the 10 August 2026 edition of the consolidated document. SharePoint Online: "Any period of time when users are unable to read or write any portion of a SharePoint Online site collection for which they have appropriate permissions." Exchange Online: "Any period of time when users are unable to send or receive email with Outlook Web Access." OneDrive for Business: "Any period of time when users are unable to view or edit files stored on their OneDrive for Business."

Read, write, send, receive, view, edit. Now set MO1456424 beside them. Affected users can read their documents and write to them, they send mail and receive mail, they view their OneDrive files and edit them. The only thing they cannot do is find, and that verb appears in none of the three definitions. Our reading: five days of a useless search box add up to zero minutes of downtime. August's availability counter stays exactly where it was.

And it is not a Microsoft trick, which is the part that tends to annoy people. Any workable SLA needs a binary definition of downtime, because it has to be measured with a clock and multiplied by affected users — the document itself counts Downtime in user-minutes. The moment you allow in "the service is slow" or "the service works, but badly," the contract stops being calculable and starts being arguable, and a contract that gets argued over is worth nothing. The price of that clarity is that what gets counted and what hurts end up being two different things.

And even if it counted, you have to ask for the credit

Suppose for a moment that it did count. SLA compensation arrives as a credit against the fee for the affected service, and it comes in bands. Below 99.9% and down to 99%, a 25% credit. Below 99% and down to 95%, 50%. Below 95%, 100%. Worth doing the arithmetic once so you never have to do it again: a 31-day month holds 44,640 minutes, so falling below 99.9% takes 44 and a half minutes of measured downtime, and falling below 99% takes 446 minutes, a good seven and a quarter hours.

And the credit does not arrive on its own. You have to claim it with the incident details, and there is a deadline: the SLA itself sets it at the end of the calendar month following the one in which the incident occurred, and illustrates it with an example that leaves no room for doubt — "if the Incident occurred on February 15th, we must receive the claim and all required information by March 31st." Somebody at your end has to gather the evidence and open the case to recover a percentage of one service's fee. Almost nobody does, and it is not laziness: the hour it costs is worth more than what you get back.

We wrote a few weeks ago that an RTO is not decided, it is measured, and that you should never sign a number you have not timed in a rehearsal. Here the problem sits one step earlier: the number in the contract is not even measuring the capability that went down. How long your business can go without being able to search, and what it does during that time, is a question a service credit does not answer.

Your monitoring measures the same thing as the SLA

This is where it stops being a complaint about Microsoft and becomes a problem at your end. Almost every synthetic check people build against a SaaS asks the same question the SLA asks: does it respond? A sign-in, an HTTP 200, a test message that goes out and comes back. All of those checks have been green all week, because all of those things were working.

The check that would have caught it is dull to build, which is why it is almost never there: a known search against fixed content, returning a result count you control. A witness document in a SharePoint site containing a rare word that appears nowhere else, and a scheduled query that says "this must return exactly 1." Technically it is no mystery, though it is not free either: you have to register an application in Entra, grant it permissions on the Graph search API and leave a scheduled job running. What changes is the question you are asking the system, which moves from "are you alive?" to "do you still know what you knew yesterday?"

Let us be honest about how far any of this goes: finding out sooner does not fix search, and neither does a backup. Nobody in legal is going to start digging for a contract in a backup console because the search box is sluggish for three days. Where a second route does decide something is one step up, the day the problem is not the index but access to the whole tenant, and we have written about that: the copy Microsoft keeps of your data never leaves Microsoft. They are two different risks, and it is worth not blurring them in order to sell the second one on the fright of the first.

When this is not your problem

Now the part that does not sell: for plenty of people this is an annoyance and nothing more. If your team works with tidy folders, known paths and the last thirty days of mail, a weak search box for a few days is inconvenient and it passes. Building an alternative search platform because of a five-day incident would be throwing money away, and we are not going to recommend it.

The question that does change things is narrower: is there a process of yours that stops if nobody can search? A legal team locating contracts by client. A support desk pulling up the mail thread for the last order. A response to a request with a legal deadline, where you have to locate everything relating to one person or one matter. If the answer is "none," congratulations, close this tab. If the answer is "that one," you now know which of your processes is fragile, and you found out for free by watching somebody else's fault.

It is the same idea we argued for about something completely different: high availability does not prevent an outage, it shortens one. No architecture promises you that nothing will happen. What gets decided in advance is how long it lasts and what you do while it lasts.

The question nobody asks at renewal

At renewal meetings the question is always "what SLA do you offer?", and the answer is always a number with three nines that says nothing on its own. The useful question is uncomfortable precisely for that reason: what exactly does your provider define as downtime, and which degradations fall outside that definition? It applies to Microsoft and it applies to anyone selling you a managed service, ourselves included. Nobody is going to rewrite an SLA for you; what you can do is find the gap before you need it, and decide with a cool head whether you cover it or carry it.

What we would do this week

• Check the message centre, not the press. If someone internally complains that "Outlook does not search," the place to confirm whether it hit you is your own tenant's service health. MO1456424 does not affect every tenant, and knowing whether you are in or out changes the answer you give your users.
• Write the answer before the next time. Two lines for the help desk: what is happening, what can be done meanwhile (folder filters, sorting by date, the direct path to the SharePoint site) and what they do not need to try. It saves half the tickets.
• Add a check on the result, not on the response. A witness document containing a unique word, a scheduled query against the search API, and an alert if the result count stops being what it should be. It is an afternoon of work once you count the app registration and the permissions, and it is the only way to find out before the person opening the ticket does.
• List the processes that depend on searching. Not the systems: the processes. Half an hour with the people who run them and you will know whether this was an annoyance or a risk. In most places the answer is reassuring; where it is not, you know where to go next.
• Keep the advisory. If any deadline-bound process was affected, Microsoft's notice with its identifier and its dates is the evidence that the cause sat with the provider. It costs nothing to save today and cannot be reconstructed in November.

With luck, by the time you read this the search box is finding things again and MO1456424 is closed. The gap between what the contract promises and what your people need is still exactly where it was.

Sources (verified on 21 August 2026): the MO1456424 identifier, the advisory title, the scope sentence and the cause "A recent deployment introduced a resource utilization inefficiency issue, leading to impact", from the service degradation notice republished by NHSmail support and from BleepingComputer's coverage of 18 August. The reports starting on Monday 17 August, the confirmation that this is not a cyberattack and the time of the next update (Friday 21 August, 04:00 UTC), from Cyber Security News. The three Downtime definitions (SharePoint Online, Exchange Online and OneDrive for Business), the measurement in user-minutes, the service credit bands, the claim deadline and its 15 February example, from the consolidated Microsoft SLA for Online Services, 10 August 2026 edition (direct link to the document; the download index also lists the other languages). The reading that a broken search fits none of those definitions is ours and is declared as such in the text; the arithmetic behind the 44 and a half minutes and the 446 minutes comes from applying the percentages to the 44,640 minutes of a 31-day month. Quotes are left in English, their original language, so they can be verified word for word.