An Azure OpenAI outage postmortem

On January 27, 2026, about an hour before a scheduled client demo, Azure OpenAI Service in Sweden Central went down. Cascading failures from an unhealthy backend service. Our AI features stopped working.

Not the best timing.

I checked status.azure.com and found this:

Azure OpenAI Service — Sweden Central Starting at 09:00 UTC on 27 January 2026, customers using Azure OpenAI Service in Sweden Central may experience intermittent availability issues. Elevated error rates and reduced availability due to unhealthy backend dependent service, which led to cascading failures.

Not my code. Not my config. The entire region’s OpenAI service was degraded.

But the incident got me thinking about what we should actually do about cloud AI reliability—and what’s probably not worth the effort.

Not everything needs the same level of protection

This is the part most “cloud resilience” articles skip. They tell you to build multi-region failover, add backup providers, cache everything. That’s fine advice if you’re running critical infrastructure. But most of us aren’t.

Large enterprises tier their infrastructure by criticality. Some things need near-100% availability. Other things can tolerate downtime. They don’t treat everything the same, because that would be expensive and pointless.

Same logic applies here. Ask yourself:

• If the AI feature is down for 2 hours, what happens? Annoyed users? Lost revenue? Safety issues?
• Is this a nice-to-have feature or core to the product?
• Can users do their job without it temporarily?

If downtime is annoying but survivable, maybe you just accept the risk and move on. If it’s genuinely critical, then invest in resilience—for that specific thing.

What’s usually worth doing

Basic monitoring and alerting. Know when things break before your users tell you. Subscribe to your cloud provider’s status page. Set up Azure Monitor alerts on your OpenAI resource’s availability metrics. This costs almost nothing and saves you from finding out about outages from your clients.

I found out about the January 27 outage at ~10:00 CET by debugging locally. The incident started at 09:00 UTC. If I had alerts configured, I would have known immediately and saved myself 15 minutes of chasing the wrong problem.

Timeouts and graceful failure. When the AI service is slow or down, don’t let your whole app hang. Fail fast. Show a message. Let users continue with what they can do without AI.

Infrastructure as Code. This is what saved me during the incident. I had Bicep templates for the entire Azure OpenAI setup—resource group, OpenAI account, model deployment, RBAC. When I decided to spin up resources in West Europe, it was one az deployment command and 15 minutes of provisioning instead of 2+ hours clicking through the Azure Portal.

Externalized configuration. My OpenAI endpoint was in environment variables, not hardcoded. Secrets like API keys were in Azure Key Vault. Switching from Sweden Central to West Europe meant updating config values, not rewriting code. Use Azure App Configuration for endpoints and feature flags, and Key Vault for anything sensitive.

What might be overkill

Multi-region deployment with routing layers. Azure Front Door, API Management with backend pools, traffic managers—these work, but they add cost and complexity. For most small teams, it’s more infrastructure to maintain than the problem justifies.

Multiple AI providers as fallback. Different APIs, different model behaviors, different rate limits. The maintenance burden is real. Some large enterprises do this as a hedging strategy. But for most teams, one provider with accepted downtime risk is more practical.

Aggressive caching of AI responses. Only useful if you have repeated identical queries. Most apps don’t. Don’t add complexity for a problem you don’t have.

Self-hosted fallback models. Cool in theory. Ops nightmare in practice unless you already have the infrastructure team for it.

But what if AI is your core feature?

If your app is AI-heavy—meaning downtime doesn’t just annoy users but makes your product unusable—then you do need some failover. But it doesn’t have to be complicated.

The simplest approach: deploy Azure OpenAI in two regions, and add a try/catch in your code.

try primary endpoint (Sweden Central)
  → if fail or timeout
    → log + alert (Azure Monitor / Slack)
    → try secondary endpoint (West Europe)
      → if both fail
        → show error to user

That’s it. No extra Azure services, no routing layers, no health probe configuration. Just a second resource in another region and some basic retry logic.

Azure has paired regions designed for this. Sweden Central pairs with Sweden South, but West Europe or North Europe work as geographic fallbacks too.

The fancier solutions (API Management with circuit breaker policies, Front Door) make sense at scale when you need instant automatic failover with zero failed requests. But for most apps, a few hundred milliseconds of retry is fine and costs nothing extra to implement.

The honest takeaway

Cloud AI services fail sometimes. That’s reality. The right response depends entirely on what you’re building and who it’s for.

For most teams: accept some risk, handle failures gracefully, monitor so you know when it happens, and don’t over-engineer.

For AI-heavy products: add a second region and simple retry logic. Keep it boring.

For critical systems at scale: invest in proper infrastructure. But be honest about whether you’re actually there yet.

Oh, and the demo? We checked Azure’s status page, saw Sweden Central was the problem, spun up a new Azure OpenAI resource in another region, swapped the endpoint, and made it in time. Sometimes the fix is simpler than the architecture discussions that follow.

Building AI on Azure and want help with reliability, RAG, or agents? I take on short, scoped consulting engagements — see how to work with me.