This piece goes through the events in a Zee Business tracker published on November 13. It checks them against the providers' own incident reports where those were available, and it corrects a few details in the tracker.
Why the tracker's table needs caveats
Zee Business is upfront about its main limit. Outage reports, affected cloud customers and affected individual users are three different measures, and for most of these events no one has published a verified count of people affected. Downdetector figures are user-submitted complaints, not a census.
A few details in the tracker don't line up with primary sources:
- The "Google App outage in New York" heading is wrong. The text under it describes a Google Cloud incident in the europe-west2 region, which is London, on October 19–20.
- Some durations differ from official figures. The Cloudflare incident is listed as 5 hours 7 minutes in the tracker's table, while Cloudflare's own postmortem says 6 hours 7 minutes.
- The Azure East US entry only says "April 2026." Microsoft's history gives a specific window on April 24.
- The AWS Middle East "ongoing" status is the tracker's claim. The tracker ties it to a November 10 update, and I could not independently confirm it.
Microsoft and Azure incidents
Azure West US, February 7–8: a transformer failure and a stuck switch
Microsoft's post-incident review describes an electrical failure in an onsite transformer that cut utility power to a datacenter. The generators started as designed. A cascading control-system failure then blocked the automatic transfer of load to them. UPS batteries carried the load for several minutes before depleting, and customer impact started at 07:58 UTC on February 7, according to the review.
Recovery was uneven. The review says 90% of IT racks were back on generator power by 09:31 UTC. Two of six storage scale units then had nodes that failed to finish booting, and manual work was needed to bring them back. All affected services were confirmed mitigated at 04:24 UTC on February 8.
Two practical points stand out:
- West US has no availability zones. Microsoft's review advises a multi-region strategy for mission-critical workloads. Zones were not an option in this region.
- The headline figure is not every customer's experience. Some services had much shorter windows. Azure Event Hubs and Service Bus, for example, were affected from 07:58 to 19:05 UTC on February 7.
Azure East US, April 24: a control-plane regression
Microsoft says that between 11:30 and 23:22 UTC on April 24, customers could see failures or delays when provisioning, scaling or updating resources in East US. That matches the tracker's 11 hours 52 minutes. This was a service-management problem, not a blanket outage of running workloads. A small subset of customers also saw intermittent connectivity on newly provisioned workloads, including VMs and Azure Virtual Desktop sessions.
The cause was lock contention in the Azure PubSub networking control-plane service. A latent regression in a recent update made recovery from it harder. Microsoft rolled the update back zone by zone. It then had to redo the rollback in one zone because it had not completed across all update domains. Microsoft also said some of its updates during the incident lacked specificity, and it listed communication improvements.
Azure West US 2, May 29–30: storm, cooling lockout, slow storage
Microsoft's review covers 04:24 UTC on May 29 to 02:30 UTC on May 30. A severe thunderstorm caused voltage sags and swells across several datacenter facilities. Parts of the mechanical cooling systems locked out as a protective measure. Temperatures rose, and infrastructure shut down proactively in two physical availability zones, AZ-01 and AZ-03.
Cooling was restored in under two hours. Storage validation then had to run sequentially and took about 14 hours. Application Insights and Log Analytics needed roughly six more hours to work through their backlogs, which is why the headline window runs so long.
Microsoft's analysis also contains a candid design observation. The cooling protection logic favored protecting equipment over keeping operations running, and that produced a full lockout rather than staged degradation. Microsoft said it would review that behavior.
Azure networking, September 30 to October 1, plus a separate AI incident
Two Azure events from the same stretch are easy to blur together:
- Networking, 20:30 UTC September 30 to 02:15 UTC October 1. This is the tracker's 5 hours 45 minutes. A temporary deployment restriction on gateway operating-system updates expired, and a large batch of updates resumed at once. That overwhelmed a shared regional control-plane service, and a prior change had also lengthened its processing times. Affected services included ExpressRoute Gateway, Application Gateway, Azure Firewall, Bastion, Virtual WAN and VPN Gateway. Many regions were involved. For ExpressRoute, redundant gateway instances were updated before the first had fully restored its configuration. Gateways then lost connectivity until they applied their last-known-good configuration after about 30 minutes.
- Azure OpenAI and Foundry in Sweden Central, September 29, 10:03 to 15:58 UTC. This is a separate event. A planned deployment cleared internal caches during peak traffic and defects amplified the cache misses. Traffic to a backend service rose to roughly 20 times normal. A health check that depended on database connectivity then put instances into a restart loop. Microsoft fixed it by reconfiguring that health check.
Microsoft 365, November 12–13
This is the most recent and still-moving item. According to TechRadar's live coverage, the outage began around 1pm ET on Thursday and hit Outlook, Teams and Copilot. Windows Central reported that the issues lasted at least 18 hours and that Microsoft pointed admins to incident MO1550821 in the Microsoft 365 admin center.
Microsoft's statements, as relayed by the live blogs, describe a recovery in stages. Tom's Guide quotes a Microsoft statement that the company would share a full post-incident report with root cause after recovery is complete. It also said the outage was not a cyberattack. A separate Microsoft update described shifting traffic to alternate routes where possible. Another mentioned preparing an automated process to detect and restart unresponsive servers.
There are two things to be careful about:
- The user count is unknown. The roughly 130,000 US Outlook reports at the peak are a complaint count. Microsoft has not published an affected-user total. By Friday afternoon GMT, Tom's Guide noted Downdetector reports hovering around 10,000.
- The root cause is not public yet. The tracker repeats Microsoft's general "infrastructure and server issues" wording. Wait for the post-incident report before drawing conclusions about the cause.
It also wasn't Microsoft's first big Microsoft 365 incident this year. The Register covered a January 22–23 outage that began at 1937 UTC and also hit Defender and Purview. That one lasted nearly ten hours, according to the same report.
Non-Microsoft incidents in the tracker
Cloudflare BYOIP, February 20
A subset of Bring Your Own IP customers had their routes withdrawn via BGP, starting at 17:48 UTC, per Cloudflare's postmortem. It was not an attack. A change meant to automate prefix removal contained a bug in the API query. An empty value for a parameter was read as "all BYOIP prefixes," so the cleanup task began deleting them. About 1,100 prefixes were withdrawn before engineers reverted it, roughly 25% of BYOIP prefixes. Some customers could recover by re-advertising prefixes in the dashboard after guidance at 19:19 UTC. About 300 prefixes lost their service bindings and had to be restored manually.
Cloudflare gives the total duration as 6 hours 7 minutes, so that is the number to use. The company also said this outage wasn't global but that the blast radius was unacceptably large. It said the incident related to its "Code Orange: Fail Small" push toward gradual rollouts.
AWS: Middle East and Northern Virginia
The tracker says drone strikes damaged AWS facilities in the UAE (me-central-1, from March 1) and Bahrain (me-south-1, from March 2). It says AWS told customers not to rely on those regions and that some data in affected zones could not be recovered. The tracker lists both as ongoing as of November 10. I could not independently confirm that status, so read it as the tracker's claim.
The May 7–8 US East incident was a thermal event with power loss in a single availability zone. Do not read it as all of us-east-1 failing. The tracker's 21 hours 30 minutes is time to majority recovery, which is not the same as full restoration.
Google Cloud: Netherlands and London
For europe-west4-a on July 15–16, Google's report says VMware Engine, Bare Metal Solution and NetApp Volumes were interrupted for 14 hours, 55 minutes. A 3 ms voltage drop tripped utility breakers on both feeds. The DRUPS backup on side A failed to take the load, and one row lost both feeds after a transfer failure. A chiller controller dropped offline and the redundant cooling source was unavailable because of known construction work. Data-hall temperatures reached 44°C and Google shut down workloads.
The London incident on October 19–20 involved an electrical feed already out for maintenance, a second feed fault, and generators that failed to start. The tracker says the UPS batteries were exhausted and lists Compute Engine, GKE, Cloud Run, Cloud SQL, Spanner and BigQuery among the affected services. I could not access Google's own report for that one. Treat the six-hour figure and the product list as the tracker's claims until you check the official incident entry.
What the pattern means for admins
Read across these incidents, a few things stand out:
- Power and cooling dominate the Azure and Google list. Five of the incidents involved power or thermal failure. A backup that doesn't transfer is as bad as having none.
- Control-plane changes are dangerous. The East US, Azure networking and Cloudflare incidents were all driven by changes. Gradual rollout and quick rollback mattered.
- Recovery is slower than repair. In West US and West US 2, storage and telemetry recovery stretched impact long after power or cooling came back.
- Zone redundancy has limits. Azure's East US incident moved across availability zones. West US had no zones at all. Microsoft's own advice for mission-critical workloads in several reviews is a multi-region strategy.
Practical steps that follow from Microsoft's own post-incident guidance:
- Configure Azure Service Health alerts so the right people are told about incidents.
- Check your logical-to-physical zone mapping. Microsoft notes that logical zones assigned to your subscription may map to different physical zones, and the Locations API shows the mapping.
- Use geo-redundant storage such as GRS or RA-GRS for data you need readable during a regional incident.
- Test failover. Don't assume a multi-region design works until you have exercised it.
- Plan for the Microsoft 365 layer too. Mail flow and Teams have no region you can choose to fail over to, so have a communication fallback.
The numbers in this story are not comparable. Duration, region count, customer count and downstream impact measure different things. Rank these by what matters to your own workloads, not by the headline hours.