Microsoft 365:s sökproblem MO1456424: Orsak, omfattning och lösning

Vad hände med Microsoft 365?

Microsoft 365-incidenten MO1456424 började klockan 08.46.14 UTC den 17 augusti 2026. Microsoft klassade händelsen som en tjänsteförsämring (serviceDegradation) som gjorde att vissa användare kunde få problem med att söka efter innehåll i SharePoint Online, OneDrive, Outlook på webben och Outlook för datorer. Den incidentpost som finns tillgänglig anger inget sluttid.

Det handlade alltså inte om att alla funktioner i dessa tjänster låg nere. Men när sökningen slutar fungera blir det snabbt svårt att hitta mejl, dokument och annat lagrat innehåll – även om själva filerna och brevlådorna fortfarande finns kvar.

Vilka användare påverkades?

Microsoft beskrev påverkan som begränsad till vissa användare som betjänades via den berörda infrastrukturen och försökte söka efter innehåll. Företaget angav varken hur många kunder som drabbades eller vilka länder och regioner som var berörda. Därför finns det inte stöd för att beskriva MO1456424 som ett bekräftat regionalt avbrott.

Vad orsakade MO1456424?

Microsoft uppgav att en nyligen genomförd utrullning hade introducerat ett problem med det som företaget kallade en ”ineffektiv resursanvändning”. I praktiken innebar det att den berörda sökinfrastrukturen använde sina resurser på ett ineffektivt sätt, vilket försämrade behandlingen av vissa sökfrågor.

De offentliga uppdateringarna går inte längre in på vilken kodväg, resurstyp eller tröskel som var inblandad, och beskriver inte heller exakt vilken förändring i utrullningen som utlöste felet.

Det viktiga är därför att hålla sig till det som faktiskt är belagt: problemet var kopplat till en programvaruutrullning och resursanvändningen i söktjänsten. Underlaget visar inte att det rörde sig om ett cyberangrepp, ett bekräftat regionalt nätverksfel eller en generell kapacitetskris i hela Microsoft 365.

Vilken lösning tog Microsoft fram?

Microsoft uppgav att företaget hade utvecklat och började rulla ut en korrigering för att minska resursbelastningen och återställa sökfunktionen. Andra rapporter beskrev åtgärden som en fix mot ineffektiviteten i infrastrukturen, med målet att få de berörda tjänsterna tillbaka i normal drift.

Den tillgängliga incidentposten saknar fortfarande sluttid. Den visar därför inte exakt när åtgärden var färdig för samtliga berörda användare. Det finns inte heller någon offentlig teknisk beskrivning i det tillgängliga materialet av en återställning, en permanent arkitekturförändring eller en mer detaljerad lösning.

Varför kallades det en incident om det var en tjänsteförsämring?

MO1456424 registrerades som en serviceDegradation-händelse i Microsoft 365:s material om tjänstehälsa. Klassningen betyder att Microsoft inte beskrev hela Microsoft 365-sviten som helt otillgänglig.

Det var ändå en incident eftersom en central, kundvänd funktion – sökningen – var nedsatt i flera produkter för de användare som påverkades. Microsoft har inte publicerat någon separat förklaring till varför just denna klassning valdes. Den säkraste tolkningen är därför den bokstavliga: en sökrelaterad tjänsteförsämring som sträckte sig över flera Microsoft 365-produkter, inte ett totalt avbrott i hela plattformen.

Hur skiljer sig händelsen från andra störningar?

Flera Microsoft- och Microsoftägda tjänster hade problem under samma period. Det gör det lätt att blanda ihop incidenterna, men de hade olika orsaker.

GitHub: en separat störning på 7 timmar och 47 minuter

GitHub drabbades av en separat incident den 17 augusti 2026, från 13.28 till 21.15 UTC. Störningen varade i 7 timmar och 47 minuter och gav förhöjda fel- och svarstider i bland annat Issues, pull requests, API:er, Actions och Copilot. Vid den värsta tidpunkten låg felandelen för webbtrafik och API-anrop på omkring 20 procent, medan nedladdningar av arkiv och råinnehåll nådde omkring 50 procent.

GitHub kopplade händelsen till överbelastade lastbalanserare, en felaktig policy för automatisk skalning och ett sedan tidigare oupptäckt fel i Visual Studio Codes mekanism för nya försök. Det är tekniskt skilt från den utrullningsrelaterade resursineffektivitet som låg bakom MO1456424.

Tidigare problem med Microsoft 365-sökning

Microsoft 365 har även haft andra sökrelaterade incidenter. I april 2025 upplevde användare av Outlook på webben och SharePoint Online fördröjningar eller misslyckade sökningar. Då kopplades problemen till infrastrukturkomponenter som behandlar sökfrågor och presterade under acceptabla nivåer.

OneDrive har dessutom haft separata problem där filsökningar kunde visas som tomma eller inte ge några träffar, trots att användarna visste att filerna hade laddats upp. Underlaget visar inte att dessa tidigare händelser hade samma grundorsak som MO1456424.

Julis bredare Azure- och Microsoft 365-fel

Händelsen den 23 juli 2026 var både bredare och tekniskt annorlunda. Microsofts historik för Azure anger att påverkan pågick mellan 14.44 och 19.41 UTC. En del kunder fick då anslutningsfel, högre fördröjningar eller problem att nå tjänster i Azure-regionen West US. Trafik som stannade helt inom regionen påverkades inte.

Microsoft skyllde felet på ett problem i den automatiserade nätverksunderhållsprocessen. Den tog bort IP-rutter från fler nätverksenheter än avsett, vilket störde trafiken till och från regionen. Det var ett fel i nätverkets kontrollplan – inte ett problem med sökfunktionen som i MO1456424.

Vad visar mönstret – och vad visar det inte?

Incidenterna inträffade på olika tekniska nivåer:

• MO1456424: en ny utrullning ledde till ineffektiv resursanvändning i sökinfrastrukturen.
• Githubs incident den 17 augusti: överbelastade lastbalanserare, bristande automatisk skalning och ett fel som förstärkte belastningen genom upprepade försök.
• Azure-händelsen i juli: automatiserat nätverksunderhåll tog bort för många IP-rutter.

Det finns alltså inget belägg för en gemensam grundorsak. Det går inte heller att slå fast att AI-drivet behov, Githubs planer på att bygga ut kapaciteten till tio- eller trettio gånger dagens nivå, den snabbare migreringen av GitHub till Azure eller Githubs multicloud-strategi med AWS orsakade någon av de här incidenterna. Githubs strategiska arbete med offentlig molninfrastruktur och multicloud visar inte i sig ett orsakssamband till ett specifikt avbrott.

Den mer försiktiga slutsatsen är att snabb tillväxt och allt viktigare moln- och AI-arbetslaster gör vissa skyddsåtgärder ännu mer avgörande: säkra utrullningar, realistisk kapacitetsplanering, isolering mellan fel, skydd mot så kallade retry-stormar och vältestad nätverksautomation. Flera molnleverantörer kan sprida vissa infrastrukturrisker, men multicloud hindrar inte automatiskt ett fel i en tjänsts eget kontrollplan.