Microsoft Azure fikk to separate driftsstans på under 48 timer i slutten av september 2026, og den første rammet direkte i Norden. Mellom 29. september og 1. oktober tapte kunder i Sweden Central-regionen tilgang til Azure OpenAI Service og Foundry-tjenestene i nesten seks timer, før en helt annen feil slo ut nettverkstilkoblinger i 18 regioner over hele kloden. Hendelsene er ikke knyttet til samme rotårsak, men de treffer samme uke, og de reiser samme spørsmål for norske og nordiske IT-ledere: hvor sårbare er egne systemer når de er bygget på én regions oppetid?
Dette er den andre større Azure-hendelsen nordiske kunder har merket i løpet av høsten, og den kommer samtidig som flere norske og svenske virksomheter flytter AI-arbeidsbelastninger til skyen i stort tempo. Denne artikkelen går gjennom tidslinjen, hva Microsoft selv har bekreftet, hvordan hendelsen måler seg mot tilsvarende feil hos AWS og Google Cloud, og hva den sannsynligvis betyr for skyarkitektur i Norden fremover.
To hendelser, 40 timer: hva som faktisk skjedde
Det er lett å forveksle de to hendelsene fordi de ligger så tett på hverandre, men de rammet forskjellige tjenester og hadde etter alt å dømme forskjellige tekniske årsaker. Den første begynte klokken 10:03 UTC den 29. september 2026, da Microsofts eget statusarkiv registrerte en plattformfeil som traff Azure OpenAI Service, Foundry Agent Service, Foundry Models og Cognitive Services i Sweden Central. Feilen varte til 15:58 UTC samme dag, en periode på fem timer og 55 minutter.
Den andre hendelsen startet klokken 20:30 UTC den 30. september, litt over et døgn etter at den første var løst. Denne gangen var det ikke AI-tjenester som ble truffet, men kjernenettverket: ExpressRoute Gateway, VPN Gateway og Azure VMware Solution (AVS). Flere rapporter nevner også forstyrrelser i Azure Firewall, Application Gateway og Web Application Firewall, selv om det klareste og mest konsekvent rapporterte omfanget er gateway-tjenestene og AVS. Denne hendelsen ble løst klokken 02:15 UTC den 1. oktober, etter fem timer og 45 minutter.
Regnet fra start av den første hendelsen til slutt på den andre, strekker det samlede krisevinduet seg over nesten 40 timer. Det er viktig å være presis her: dette var to separate, uavhengige hendelser, ikke én sammenhengende utfall. Men for en kunde med arbeidsbelastninger som både kjører AI-modeller i Sweden Central og kobler lokale datasentre til Azure via ExpressRoute, kunne uken fortone seg som én lang periode med redusert drift.
Sweden Central: fem timer og 55 minutter uten AI-svar
Microsofts egen statushistorikk beskriver symptomene som “intermittent request failures, increased latency, and HTTP 5XX error codes” for kunder som sendte forespørsler mot modeller og API-er i regionen. Oversatt til praksis betyr det at applikasjoner som kaller Azure OpenAI eller Foundry Models i Sweden Central, fikk tidsavbrudd, forsinkede svar eller rene feilmeldinger i stedet for genererte svar. For en chatbot, et kundeserviceverktøy eller en intern AI-agent bygget på disse tjenestene, er dette i praksis full nedetid i brukeropplevelsen, selv om Microsoft formelt beskriver det som «intermitterende» feil snarere enn totalt bortfall.
Microsoft har ikke offentliggjort en detaljert teknisk rotårsaksanalyse for Sweden Central-hendelsen i materialet som er tilgjengelig ved publisering. Selskapets statusoppdateringer beskriver en «platform issue» og bekrefter at team jobbet med å identifisere og håndtere problemet, men går ikke inn i om det var en feilslått utrulling, en maskinvarefeil, en avhengighetsfeil eller noe annet som utløste problemet.
Gateway-kollapsen: 18 regioner, samme uke
Den andre hendelsen hadde et vesentlig bredere geografisk fotavtrykk. Ifølge rapportering fra The Register, som siterer Microsofts egne hendelsesvarsler, ble totalt 18 Azure-regioner rammet: West US, West US 3, North Europe, West Europe, France Central, UK West, UK South, Switzerland North, Southeast Asia, East Asia, Japan West, Korea Central, South Africa North, UAE North, Mexico Central, Germany North, South India og Jio India Central. Merk at ingen av de nordiske regionene, inkludert Sweden Central, sto på denne listen, selv om kunder med hybride tilkoblinger via disse 18 regionene kan ha merket indirekte konsekvenser uansett hvor hovedkontoret deres ligger.
Konsekvensene varierte fra sted til sted. Noen kunder opplevde at nettverksporter ikke lastet i Azure-portalen, andre fikk redusert redundans på VPN-tunneler uten at selve tilkoblingen falt helt ut, og noen mistet muligheten til å utføre nettverksadministrasjon midlertidig. Felles for de fleste rapportene er at dette primært traff hybride miljøer: bedrifter som kobler egne datasentre til Azure via ExpressRoute, driver VPN-tunneler for eksterne kontorer, eller kjører VMware-arbeidsbelastninger i AVS.
Ifølge The Register er hendelsen knyttet til infrastrukturvedlikehold eller OS-servicing som gikk galt, og Microsoft skal ha satt driftsoppdateringer på pause mens de undersøkte omfanget. Samtidig understreker samme rapportering at Microsoft ved skrivende stund ikke hadde publisert en fullstendig, bekreftet rotårsak utover denne vedlikeholdskonteksten. «Mislykket vedlikehold» er altså en rimelig beskrivelse basert på det som er kjent, men ikke nødvendigvis selskapets endelige offisielle forklaring.
Tidslinjen i tall
Tabellen under oppsummerer de to hendelsene side om side, basert på Microsofts egen statushistorikk og uavhengig rapportering fra The Register.
| Hendelse | Start (UTC) | Slutt (UTC) | Varighet | Rammede tjenester | Geografisk omfang |
|---|---|---|---|---|---|
| Sweden Central AI-feil | 29. sep 2026, 10:03 | 29. sep 2026, 15:58 | 5 t 55 min | Azure OpenAI, Foundry Agent Service, Foundry Models, Cognitive Services | 1 region (Sweden Central) |
| Gateway/hybrid-feil | 30. sep 2026, 20:30 | 1. okt 2026, 02:15 | 5 t 45 min | ExpressRoute Gateway, VPN Gateway, Azure VMware Solution | 18 regioner globalt |
| Samlet krisevindu | 29. sep 2026, 10:03 | 1. okt 2026, 02:15 | Ca. 40 timer | To uavhengige feil, ikke én sammenhengende hendelse | Global, med nordisk AI-nedetid |
Det som gjør denne uken spesielt ubehagelig for driftsansvarlige, er ikke nødvendigvis varigheten på hver enkelt hendelse. Fem til seks timer er alvorlig, men ikke enestående i skybransjen. Det som skiller denne uken ut, er at to strukturelt forskjellige deler av Azure-plattformen, AI-laget og nettverkslaget, sviktet med bare et døgns mellomrom. Det er nettopp den typen korrelasjon som gjør det vanskeligere for et driftsteam å stole på at det bare er en forbigående feil denne gangen.
Hvorfor dette er mer enn en teknisk fotnote for Norden
Sweden Central er en av Microsofts regioner i Norden, og den brukes aktivt av kunder som ønsker drift og databehandling innenfor nordisk eller europeisk jurisdiksjon. Når AI-tjenestene i nettopp denne regionen går ned i nesten seks timer, er det et direkte treff mot den typen regional nærhet mange nordiske virksomheter har valgt Sweden Central for i utgangspunktet. En bedrift som har bygget sin AI-arkitektur rundt én region, enten av regulatoriske hensyn, latenskrav eller ren vane, har ingen innebygd beskyttelse mot nettopp denne typen regional feil.
Det samme gjelder gateway-hendelsen, selv om Sweden Central ikke sto på listen over de 18 rammede regionene. Mange norske og svenske selskaper med hybride miljøer, altså en kombinasjon av eget datasenter og Azure, ruter trafikken sin gjennom ExpressRoute-forbindelser som fysisk kan terminere i europeiske knutepunkter som North Europe eller West Europe, begge på listen over rammede regioner. En nordisk bedrift trenger ikke ha arbeidsbelastninger fysisk plassert i en rammet region for å merke konsekvensene av at forbindelsen dit svikter.
Dette kommer samtidig med at stadig flere nordiske virksomheter flytter tyngre AI-arbeidsbelastninger til skyen. Interessen for Azure OpenAI Service og Foundry-plattformen har økt kraftig i norske og svenske foretak gjennom 2026, drevet av behovet for å bygge interne kopiloter, kundeserviceautomatisering og dokumentbehandling uten å drifte egne GPU-klynger. Når disse arbeidsbelastningene i økende grad flyttes til en enkelt regional AI-tjeneste, blir sårbarheten for regionale utfall tilsvarende større, ikke mindre.
Hva Microsoft faktisk har bekreftet
Microsoft kommuniserer primært gjennom sitt offentlige statusarkiv, ikke gjennom pressemeldinger eller talspersoner, noe som er typisk for driftshendelser av denne typen. Flere av de offisielle meldingene er verdt å sitere direkte, fordi ordlyden sier noe om hvor tekniske og forsiktige disse varslene er formulert.
Om Sweden Central-hendelsen skrev Microsoft Azure Status: “Starting at 10:03 UTC and 15:58 UTC on 29 September 2026, a platform issue resulted in impact to Azure OpenAI Service, Foundry Agent Service, Foundry Models, and Cognitive Services, in the Sweden Central region.” (Microsoft Azure Status)
I den første, løpende varslingen før full bekreftelse het det: “We are investigating an issue affecting Azure OpenAI Service, Azure AI Foundry Agent Service, Azure AI Foundry Models, and Azure AI Cognitive Services in the Sweden Central region.” (Microsoft Azure Status)
Konsekvensene for kundene ble beskrevet nøkternt: “Impacted customers may experience intermittent request failures, increased latency and HTTP 5XX error codes when making service requests.” (Microsoft Azure Status)
For gateway-hendelsen var varselet enda mer presist på klokkeslett: “Starting at 20:30 UTC on 30 September 2026, a subset of customers using gateway services in multiple regions experienced degraded or interrupted network connectivity.” (Microsoft Azure Status)
Og om den konkrete brukeropplevelsen: “Impacted customers may have observed gateways failing to load in the Azure Portal, along with failures or delays in network management operations across the following impacted services.” (Microsoft Azure Status)
Det er verdt å legge merke til hva disse meldingene ikke sier. Ingen av dem nevner en spesifikk feilkilde, et endringsnummer, eller et estimat for hvor mange kunder som var berørt. Det er standard praksis i bransjen å holde slike detaljer til en etterfølgende rapport, en såkalt rotårsaksanalyse, men det betyr også at kunder i praksis må vente lenger på svar om hvorvidt eget oppsett bidro til problemet, eller om feilen lå helt og fullt på Microsofts side.
Slik måler Azure seg mot AWS og Google Cloud i 2026
Ingen av de tre store skyleverandørene har hatt et problemfritt 2026. Google Cloud har hatt flere regionale hendelser gjennom året, inkludert et utfall i us-west1-regionen 20. august som varte 2 timer og 22 minutter ifølge Googles egen statusside, og en mer alvorlig hendelse i europe-west4-a 15. til 16. juli, der en kjølefeil etter et spenningsfall fikk temperaturen i datahallen til å stige til 44 grader og forårsaket et avbrudd som enkelte kilder, deriblant skyavbrudds-oversikten til Axis Intelligence, oppgir til nesten 15 timer. AWS har på sin side hatt gjentatte problemer i sin kritiske us-east-1-region. Ifølge samme oversikt skal en kjølefeil i en enkelt tilgjengelighetssone ha ført til et avbrudd på rundt 28 timer i starten av mai.
Det finnes også en mer debattert påstand om Azures historiske driftsmønster. Rådgivningsmiljøet 360 Technology Hub publiserte i juni 2026 en analyse på LinkedIn der de hevder at Azure i perioden 2024 til 2025 hadde ni større hendelser med en gjennomsnittlig varighet på 14,6 timer, mot et gjennomsnitt på 1,5 timer for AWS og 5,8 timer for Google Cloud i samme periode, inkludert en enkelthendelse i East US 2 på hele 48 timer. Dette er ikke en tallstørrelse fra et uavhengig analysehus som Synergy Research eller Gartner, og bør leses som en bransjeanalyse snarere enn en revidert bransjestandard. Likevel er det en påstand som sirkulerer blant drifts- og arkitekturfolk, og den underbygger et mønster mange kjenner igjen fra uken som nettopp er beskrevet: når noe går galt hos Microsoft, har det en tendens til å ta lengre tid å løse enn tilsvarende feil hos de to konkurrentene.
| Leverandør | Dato | Region | Varighet | Årsak |
|---|---|---|---|---|
| Azure | 29. sep 2026 | Sweden Central | 5 t 55 min | Plattformfeil (ikke fullt forklart) |
| Azure | 30. sep–1. okt 2026 | 18 regioner globalt | 5 t 45 min | Infrastrukturvedlikehold/OS-servicing |
| Google Cloud | 20. aug 2026 | us-west1 | 2 t 22 min | Fibervedlikehold, mislykket omruting |
| Google Cloud | 1. sep 2026 | us-central1-b | 14 min–4 t 8 min (varierte per tjeneste) | Menneskelig feil under vedlikehold av fiberforbindelser |
| Google Cloud | 15.–16. jul 2026 | europe-west4-a | Ca. 12–15 timer | Spenningsfall utløste kjølefeil |
| AWS | 7.–8. mai 2026 | us-east-1 (use1-az4) | Ca. 28 timer | Kjølefeil i datasenterhall |
Et mønster som går igjen i nesten alle disse hendelsene, uavhengig av leverandør, er at den underliggende utløseren ofte er fysisk infrastruktur: kjøling, strøm, fiberforbindelser og vedlikeholdsrutiner, snarere enn ren programvarefeil i applikasjonslaget. Det er en nyttig påminnelse om at skyen aldri har vært immun mot de samme fysiske sårbarhetene som rammer tradisjonelle datasentre. Den har bare flyttet ansvaret for å håndtere dem fra kundens eget driftsteam til leverandørens.
Samme uke: en containerfeil hos Cloudflare underbygger et bredere mønster
Azure var ikke den eneste infrastrukturleverandøren med en pinlig uke i slutten av september 2026. Cloudflare bekreftet 24. september at de hadde tettet en sårbarhet i Containers-plattformen som gjorde det mulig for én betalende kunde å lese rundt 60 KB med gjenværende data fra en annen kundes tidligere arbeidsbelastning på samme fysiske server. Feilen var knyttet til en lagringsinnstilling kalt skip_block_zeroing, som gjorde at en 64 KB lagringsblokk ikke ble fullstendig tømt før den ble gjenbrukt av en ny container. Cloudflares egen interne revisjon fant gjenværende data på 18 av 24 testede plasseringer og 20 av 22 underliggende servere, spredt over fire kontinenter, ifølge rapportering fra The Hacker News. Shattered.io dekket denne hendelsen i detalj i artikkelen om Cloudflare Containers-hullet som ble tettet på åtte timer.
Sammenhengen mellom de to sakene er ikke teknisk, de deler ingen kode eller infrastruktur, men de deler et tidspunkt og et budskap: multi-tenant skyplattformer, enten det gjelder containere, nettverk eller AI-modeller, har flere svake punkter samtidig i 2026 enn mange kunder antar. For et driftsteam som skal prioritere risiko, er det et argument for å behandle leverandøravhengighet som en løpende øvelse, ikke en engangsvurdering gjort ved valg av skyplattform.
Historisk kontekst: Azure har vært her før
September-hendelsene er ikke Azures første møte med lengre driftsstans de siste årene. Microsoft 365- og Azure Active Directory-tjenester, som i dag utgjør identitetsryggraden for mange Azure-arbeidsbelastninger, har hatt flere alvorlige hendelser siden 2020. En global innloggingsfeil 28. september 2020 varte rundt fem timer og ble knyttet til en Azure AD-oppdatering med en latent kodefeil, ifølge en samlet historisk oversikt over Microsoft 365-driftsstans. Et tilsvarende problem 15. mars 2021 rammet Teams, Exchange Online og innlogging til Microsoft 365 globalt i rundt to timer, denne gangen knyttet til rotasjon av autentiseringsnøkler.
Senere, i november 2024, registrerte sporingsprosjektet CalCompute en hendelse på rundt 19 timer, og samme datasett nevner en enda lengre hendelse i Azures China North 3-region på nærmere 50 timer, omtalt som den lengste enkelthendelsen i målingsperioden. 29. oktober 2025 opplevde Microsoft 365 og Azure på nytt et globalt utfall, denne gangen rapportert å vare om lag 8,2 timer, og sekundære rapporter har knyttet dette til en konfigurasjonsendring i Azure Front Door. Microsoft har ikke offentliggjort en fullstendig verifisert rotårsaksrapport med alle disse detaljene i materialet som er tilgjengelig her, så de eksakte tekniske forklaringene bør leses som sekundær rapportering, ikke som en bekreftet, Microsoft-publisert etterevaluering.
Det finnes også et velkjent eksempel på hvor store konsekvenser en enkelt feil i skyøkosystemet kan ha, selv når feilen ikke kommer direkte fra skyleverandøren selv. 19. juli 2024 førte en feilaktig oppdatering fra sikkerhetsleverandøren CrowdStrike til at rundt 8,5 millioner Windows-maskiner verden over krasjet, mange av dem knyttet til Azure-baserte virksomhetssystemer. Hendelsen er ikke en Azure-feil i teknisk forstand, men den illustrerer hvor tett sammenvevd moderne skyinfrastruktur er, og hvor fort en enkelt feilkilde kan spre seg til millioner av endepunkter.
SLA, kompensasjon og hva kundene faktisk kan kreve
Et av de første spørsmålene mange driftsledere stiller etter en hendelse som dette, er om de har rett på kompensasjon. Svaret er mer komplisert enn mange tror. Microsoft publiserer tjenestespesifikke avtaler om tjenestenivå for Azure, og disse er ikke universelle. Det finnes altså ikke én «Azure-SLA» som dekker alle tjenester likt. I stedet garanterer de fleste databehandlings- og nettverkstjenester typisk mellom 99,9 og 99,99 prosent oppetid per måned, med gradvis stigende krediteringssatser dersom leverandøren faller under grensen, dokumentert i Microsofts offisielle oversikt over tjenestenivåavtaler.
I praksis betyr dette at en kunde som ble rammet av Sweden Central-hendelsen, må beregne sin egen nedetid for akkurat den tjenesten de brukte, sette den opp mot avtalt oppetidsgaranti for den måneden, og sende inn et krav innen fristen som gjelder for akkurat den avtalen. Standard unntak dekker ofte ting som planlagt vedlikehold, force majeure og feil utenfor leverandørens kontroll, og disse unntakene varierer fra tjeneste til tjeneste. Det finnes ikke offentlig informasjon om at Microsoft har annonsert en egen, utvidet kompensasjonsordning spesifikt for september-hendelsene, utover de standard SLA-kanalene som allerede gjelder.
Hvorfor statussider alene ikke er nok
En gjennomgående kritikk fra driftsmiljøer etter begge hendelsene handler om varslingskanalene selv, ikke bare om de underliggende feilene. Azures offentlige statusside og tilhørende RSS-feed oppdateres manuelt av Microsofts driftspersonell, noe som betyr at det kan ta tid fra et problem oppstår til det faktisk vises som bekreftet på siden. For et team som overvåker egen produksjon, er det en tynn margin: hvis overvåkningen alene lener seg på Microsofts statusvarsler, kan egne alarmer trigge lenge før den offisielle bekreftelsen dukker opp, eller i verste fall etter at kunden allerede har mistet tillit til egne systemer internt.
Praktisk lærdom for driftsteam er derfor å bygge egen, uavhengig overvåkning av kritiske Azure-avhengigheter, i tillegg til å abonnere på Microsofts statusvarsler. Det kan være så enkelt som periodiske helsesjekker mot egne endepunkter i Sweden Central, kombinert med varsling dersom responstiden eller feilraten avviker fra normalen, uavhengig av hva den offisielle statussiden viser på et gitt tidspunkt.
Markedseffekten: konkurrenter, tillit og flyttebeslutninger
Det er fortsatt for tidlig å måle en konkret markedsandelseffekt av denne uken, og det finnes ingen bekreftet tallstørrelse som viser at kunder har flyttet arbeidsbelastninger bort fra Azure som direkte følge av disse to hendelsene. Det som derimot er tydelig, er at episoden gir AWS, Google Cloud og mindre nordiske aktører som UpCloud et konkret argument å bruke i salgssamtaler mot Azure-kunder: historien om at Microsofts hendelser i snitt tar lengre tid å løse enn konkurrentenes, selv om den historien bygger på en enkelt bransjeanalyse og ikke en revidert industristandard.
For nordiske virksomheter med forpliktelser til regulatorer, enten gjennom NIS2-regelverket eller EUs Cloud and AI Development Act, blir hendelser som dette også relevante i en annen sammenheng: dokumentasjonskrav. Begge regelverk legger økende vekt på at virksomheter skal kunne vise til risikovurderinger og kontinuitetsplaner for kritiske leverandører. En driftsstans i en navngitt region, med offentlig tidslinje og offisielle statusmeldinger, er nettopp den typen hendelse en risikovurdering bør ha tatt høyde for i forkant, og som revisorer og tilsynsmyndigheter sannsynligvis vil spørre om i etterkant.
Fem prediksjoner for de neste månedene
- Strengere endringskontroll: Microsoft vil mest sannsynlig stramme inn rutinene for infrastrukturvedlikehold og utrulling av OS-oppdateringer på nettverkslaget, etter at gateway-hendelsen ble knyttet til nettopp denne typen vedlikehold.
- Mer press for multiregion-arkitektur: Flere nordiske virksomheter som i dag kjører AI-arbeidsbelastninger i en enkelt Azure-region, vil sannsynligvis begynne å bygge failover til en sekundær region eller en sekundær leverandør for forretningskritiske AI-tjenester.
- Konkurrentene skjerper budskapet: AWS, Google Cloud og nordiske skyleverandører vil bruke hendelsen aktivt i sine salgsargumenter mot eksisterende og potensielle Azure-kunder i regionen.
- Flere kompensasjonskrav, men begrenset utbetaling: Antall SLA-krav fra storkunder vil øke i tiden etter hendelsen, men standard unntak og tjenestespesifikke grenser betyr at de faktiske utbetalingene sannsynligvis blir langt mindre enn kundenes opplevde tap.
- Tettere regulatorisk interesse: Tilsynsmyndigheter knyttet til NIS2 og EUs skyregulering vil i økende grad etterspørre dokumentasjon fra virksomheter om hvordan de håndterer avhengighet av enkeltregioner hos store skyleverandører.
Hva bedrifter i Norge og Norden bør gjøre nå
Det viktigste konkrete skrittet er å kartlegge hvor mye av egen drift som i praksis er avhengig av en enkelt Azure-region. For AI-arbeidsbelastninger betyr det å sjekke om modellkall til Azure OpenAI eller Foundry har en reserveløsning i en annen region, eller om en feil i Sweden Central i praksis betyr full nedetid for egne systemer. For hybride miljøer betyr det å vurdere om det finnes en alternativ tilkoblingsvei dersom ExpressRoute- eller VPN-forbindelsen til en bestemt region svikter, for eksempel gjennom en sekundær krets til en annen region.
Driftsteam kan også overvåke egen tjenestehelse direkte mot Azures API, i stedet for å stole alene på statussiden i portalen. Et enkelt eksempel med Azure CLI for å sjekke ressurshelse for en ressursgruppe ser slik ut:
az resource-health metadata list \
--resource-group min-ressursgruppe \
--output tableI tillegg bør kontinuitetsplaner oppdateres med denne hendelsen som konkret case: hva var faktisk nedetiden for egne tjenester, hvor lang tid tok det å oppdage feilen internt, og hvilke manuelle eller automatiserte tiltak ble, eller burde ha blitt, satt i verk. Dette er også dokumentasjon som er direkte relevant opp mot NIS2-kravene om risikostyring for digital infrastruktur.
Norske virksomheter som vurderer skyleverandør for AI-arbeidsbelastninger finner mer bakgrunn om hvordan de store aktørene har prestert i vår oversikt over skyfeil i august 2026, i vår tidligere dekning av Google Cloud-bruddet i Iowa, og i vår gjennomgang av hvordan skysuverenitet snur Norden. Bedrifter som fortsatt kjører VMware-arbeidsbelastninger i Azure bør også se vår artikkel om prisøkningen fra Broadcom som driver nordiske firmaer mot skyen, siden AVS var en av tjenestene som ble rammet av gateway-hendelsen.
Ofte stilte spørsmål
Hva skjedde med Azure i Sverige i slutten av september 2026?
En plattformfeil i Sweden Central-regionen slo ut Azure OpenAI Service, Foundry Agent Service, Foundry Models og Cognitive Services i fem timer og 55 minutter, fra 10:03 til 15:58 UTC den 29. september 2026, ifølge Microsofts egen statushistorikk.
Var dette samme feil som gateway-hendelsen som rammet 18 regioner?
Nei. Dette var to separate hendelser. Gateway-hendelsen startet 20:30 UTC den 30. september og ble løst 02:15 UTC den 1. oktober, og rammet ExpressRoute Gateway, VPN Gateway og Azure VMware Solution i 18 regioner, ikke i Sweden Central.
Hvilke 18 regioner ble rammet av gateway-feilen?
West US, West US 3, North Europe, West Europe, France Central, UK West, UK South, Switzerland North, Southeast Asia, East Asia, Japan West, Korea Central, South Africa North, UAE North, Mexico Central, Germany North, South India og Jio India Central, ifølge rapportering fra The Register basert på Microsofts hendelsesvarsler.
Hva var årsaken til driftsstansen, ifølge Microsoft?
For Sweden Central har Microsoft kun bekreftet en «platform issue» uten ytterligere teknisk detalj. For gateway-hendelsen peker rapportering fra The Register mot infrastrukturvedlikehold eller OS-servicing som gikk galt, men Microsoft hadde ikke offentliggjort en fullstendig rotårsaksanalyse ved publiseringstidspunktet.
Får nordiske Azure-kunder kompensasjon for nedetiden?
Eventuell kompensasjon følger Microsofts standard, tjenestespesifikke SLA-er, som typisk garanterer mellom 99,9 og 99,99 prosent oppetid med stigende krediteringssatser ved brudd. Det finnes ingen offentlig kjent, utvidet kompensasjonsordning spesifikt for disse to hendelsene.
Er dette vanlig for Azure, eller en enkeltstående hendelse?
Azure, AWS og Google Cloud har alle hatt flere regionale driftsstans gjennom 2026. En bransjeanalyse delt av rådgivningsmiljøet 360 Technology Hub hevder at Azure i 2024 til 2025 hadde lengre gjennomsnittlig hendelsesvarighet enn AWS og Google Cloud, men dette er ikke bekreftet av et uavhengig analysehus og bør leses som en enkeltstående analyse, ikke en revidert bransjestandard.
Hva bør bedrifter gjøre for å redusere risikoen?
Kartlegg hvilke arbeidsbelastninger som er avhengige av en enkelt Azure-region, bygg reserveløsninger for forretningskritiske AI-kall og nettverkstilkoblinger, overvåk tjenestehelse direkte via Azures API i tillegg til portalen, og oppdater kontinuitetsplaner med konkrete tall fra denne hendelsen som case.
Hvor finner jeg offisiell, oppdatert status fra Microsoft?
Microsofts statushistorikk oppdateres løpende og er den mest pålitelige primærkilden for nøyaktige klokkeslett og offisielle beskrivelser av hvilke tjenester som er rammet til enhver tid.
