Mistral Large on Sweden Central – 429, 500 & 503 errors since this morning

Update with isolation test (2026-05-13):

Performed control test on same Azure OpenAI resource (Sweden Central):
- Endpoint:   https://openai-hol09-prod-sw.openai.azure.com/openai/v1
- gpt-4o deployment      → SUCCESS in <5s
- Mistral-Large-3 deploy → APITimeoutError after 60s

This isolates the issue to the Mistral serving path specifically, not the
Azure OpenAI gateway or Sweden Central region overall.

Consistent with stack trace from Azure portal playground (Apim-request-id
52c8c0aa-dac0-40aa-b236-ca76c150f6a4):
  httpx.ConnectTimeout
  File ".../microsoft-maas/billingproxy/apis/mistral/chat.py", line 113, in chat
  → downstream_client_getter().send(...) cannot establish TCP connection
    to the Mistral inference backend.

Other reproduced Apim-request-ids on Mistral-Large-3 with consistent symptoms:
  - 5a2ffca6-2a60-4a6e-b0b3-e144e2ea8e00  (engine_timeout 3804)
  - 237dc4b5-1941-4164-9522-415a9ff2a3c1  (no healthy upstream)

The MaaS billing proxy layer is unable to reach the downstream Mistral
inference service. This appears to be a Mistral-specific backend connectivity
issue, not a broader Foundry/region outage.

Hello @Gregory Verey

Thank you for Reaching out Microsoft Q&A.

From your description, you are observing intermittent:

• HTTP 429 (Too Many Requests),

• HTTP 500 (Internal Server Error),

• and HTTP 503 (Service Unavailable)

when calling the Mistral Large serverless/pay-as-you-go deployment in Sweden Central, despite remaining within expected quota limits and without any recent configuration changes.

Since GPT deployments appear to be functioning normally, the issue is isolated to Mistral Large deployments, and the failures started suddenly without traffic spikes or redeployments,

this currently appears consistent with a transient backend/service-side issue affecting the Mistral inference path in the Sweden Central region.

The combination of 429 responses despite available quota, intermittent 500/503 errors, and request instability typically indicates temporary backend capacity pressure, routing instability, or inference service connectivity issues rather than a client-side configuration problem.

At the moment, there is no publicly posted Azure incident specifically for Sweden Central Mistral deployments, however the relevant infrastructure/service teams are currently investigating similar reports.

Recommended actions:

• implement retry logic with exponential backoff for 429/500/503 responses,

• monitor Azure Service Health and Resource Health for Sweden Central updates,

• If possible, temporarily route Mistral workloads to another supported region such as West Europe to validate whether the issue is region-specific.

If high availability is required during the investigation, you may also consider deploying to another supported region, or using provisioned/dedicated capacity where applicable.

Please also help validate whether all Mistral deployments in the region are impacted, whether the issue affects only serverless/pay-as-you-go endpoints, and whether latency increased before the failures started.

Troubleshoot Foundry/AML online endpoints: https://learn.microsoft.com/azure/machine-learning/how-to-troubleshoot-online-endpoints

Troubleshoot deployments & monitors in Azure AI Foundry: https://learn.microsoft.com/azure/ai-studio/how-to/troubleshoot-deploy-and-monitor

Azure Service Health & Resource Health overview: https://learn.microsoft.com/azure/service-health/resource-health-overview

I Hope this helps. Do let me know if you have any further queries.

Thank you!

Hi @Gregory Verey

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!