Azure details separate AI and gateway service incidents
Microsoft has mitigated two Azure disruptions. Preliminary accounts describe different causes, with further reviews pending.
Microsoft’s Azure status history lists two mitigated incidents with different preliminary explanations. Final incident reviews are pending.
On September 29, Azure OpenAI, Foundry Agent Service, Foundry Models and Cognitive Services in Sweden Central suffered intermittent failures and latency from 10.03 to 15.58 UTC. Metadata service timeouts and repeated restarts reduced healthy capacity. Microsoft scaled the backend, adjusted limits and disabled an automated health check.
A gateway incident ran from September 30 at 20.30 UTC to October 1 at 02.15 UTC across multiple regions. A gateway manager change combined with operating system servicing to create excess load and scaling problems. Microsoft paused servicing and reverted the change. Affected services included ExpressRoute Gateway, Firewall, Application Gateway, VPN Gateway and Azure VMware Solution.
That leaves 28 hours and 32 minutes between incidents, based on Microsoft’s timestamps. The published windows describe overall incident duration rather than every customer’s downtime.
Check what a health signal actually measures
Microsoft’s health endpoint guidance distinguishes whether a process is running from whether it can serve useful requests. A shallow liveness check avoids querying downstream dependencies. A deeper readiness check can test the services needed to complete a request. Restarting an application cannot repair a failed shared dependency.
For teams building AI applications, that distinction belongs in recovery testing. Make one dependency slow in a controlled environment and observe the response. Does the application stop accepting work, restart repeatedly or preserve capacity for requests it can still complete? The useful result is evidence that the recovery mechanism helps under the failure being tested.
Keep retries within a clear limit
The Azure retry pattern warns that aggressive retries can further burden a service already near capacity. It recommends matching delay and attempt limits to the workload, considering cancellation and checking whether repeated operations are safe. An interactive request may need a faster failure response than a background job.
For an AI workflow that performs actions, review the whole operation before repeating it. A missing response does not necessarily establish that an earlier step did nothing. Track which steps completed and define when the application should stop retrying and tell the user that work remains unresolved.
Connect provider notices with application evidence
Azure Service Health alerts can filter notifications by subscription, service, region and event type. Teams should check that the relevant people receive those alerts and know which application dashboards to inspect. A provider notice and the application’s own error records answer different questions. Preserve both when reconstructing an interruption.
For related observability coverage, ByteForward has examined Google bringing Cloud Trace to Agent Gateway. Tracing provides another way to investigate the path a request takes through an application.
Original AI generated conceptual illustration of two separate cloud systems
