16 posts tagged with "Cloud"

Introduction​

Multiple Google Cloud services in europe-west2 (London) experienced service disruptions, elevated error rates, API timeouts and processing latency on October 20, 2026, according to Google's incident page. Google's preliminary incident report records the start at 23:00 US/Pacific on October 19, 2026 (06:00 UTC on October 20) and the end at 05:10 US/Pacific on October 20 (12:10 UTC) - 6 hours 10 minutes. Google attributes the outage to an electrical power interruption at the datacenter facility hosting availability zone europe-west2-b. When UPS batteries depleted after backup generators failed to assume the load, hosts, network hardware and storage in that zone went offline, and failover then overloaded other zones in the region. Google says the preliminary text is its best knowledge at posting and is subject to change, and that a final incident report with preventative actions will follow once the investigation is complete.

Introduction​

Some users in Germany and the United Kingdom who reach Microsoft 365 through Global Secure Access (GSA) may have been unable to use Outlook, Outlook on the web, OneDrive, SharePoint Online, Microsoft Teams and Windows 365 Cloud PCs on October 13, 2026, according to Microsoft's service health updates as recorded by IncidentHub. Microsoft's final update records the start at 07:40 UTC and the end at 18:31 UTC the same day - about 10 hours 51 minutes - and narrows the geographic scope to Germany only. Mid-incident updates stated the cause as "a section of GSA infrastructure is performing below acceptable performance thresholds." The final update does not restate a cause, and as of this writing the status page does not mention a post-incident report.

Global Secure Access is Microsoft's Security Service Edge product, the umbrella name for Microsoft Entra Internet Access and Private Access; a Microsoft traffic forwarding profile can send Microsoft 365 traffic through it (Microsoft Learn). All updates in this outage scoped impact to users "using GSA".

Introduction​

Google Cloud Storage in us-central1 (Iowa) had elevated latency and error rates on upload and write operations on October 8, 2026, and a smaller subset of reads was also affected, according to Google's incident page. Google records the start at 11:00 UTC and the end at 23:30 UTC the same day - 12 hours 30 minutes. The outage report - fetched on October 12, 2026 - includes a preliminary incident report as of this writing. Google attributes the impact to a traffic sorting optimization that caused severe resource exhaustion on specific backend storage nodes in us-central1, and to a separate issue in the underlying database service that added metadata processing errors for part of the window. Google says the report is preliminary and a full root cause analysis is still underway.

Introduction​

Railway-hosted domains returned HTTP 404 to new connections in all four Railway regions on September 30, 2026, for about five minutes between roughly 07:35 and 07:40 UTC. This happened after a new version of Railway's routing service went live before the database schema change it depended on had been applied. Railway's report says its running workloads were not affected and no data was lost, and existing connections stayed up, although some private networking lookups between services failed in the same window.

Railway's first public status update went out at 07:48 UTC, about eight minutes after routing had recovered, and described itself as a "post facto" report. The incident was marked resolved at 08:17 UTC, and Railway published a detailed incident report on its blog at 22:42 UTC the same day.

Introduction​

Namecheap took more than 5,000 servers offline on August 13, 2026 after cooling systems failed at RadiusDC's Phoenix datacenter, and brought services back in stages over roughly 28 and a half hours. The shutdown was deliberate, intended to protect hardware from overheating. It reached most of the product line - hosting, EasyWP, Private Email, DNS management, URL redirect management and the support helpdesk - while DNS zone resolution was unaffected. The emergency maintenance post opened at 12:35 UTC on August 13 and was marked resolved at 17:00 UTC on August 14.

Introduction​

On July 24, 2026, AWS lost connectivity between the us-west-2 (Oregon) region and the Seattle Metro. The initial impact window was 20 minutes for most and 1 hour 17 minutes for a few customers using AWS Direct Connect through EqSe2, Westin Building Exchange, Seattle. Any traffic that both started and ended inside the region kept working, whereas anything crossing the region boundary saw timeouts and errors. This included the AWS Management Console for some customers.

Downstream services took longer to recover. IncidentHub recorded 9 confirmed cascade incidents across 7 providers, and 3 possible cascade events at 3 more.

Introduction​

On July 23, 2026, Microsoft Azure experienced a connectivity outage in the West US region that blocked traffic entering or leaving the region for nearly five hours. Workloads that stayed entirely inside West US were not affected. Microsoft's preliminary Post Incident Review (PIR) attributes the failure to a bug in maintenance request conversion software that removed IP routes from more devices than intended during routine device maintenance.

IncidentHub detected a wave of downstream SaaS outages tied to the Azure incident. Acknowledgement times on those status pages varied widely - from a few minutes to more than three hours after Azure's impact began.

Introduction​

Last updated on October 7, 2026.

The first half of 2026 reinforced a key idea about Cloud and SaaS reliability - dependency risk. IncidentHub tracked 30,246 outages across 1,082 providers between January and June 2026. May was the busiest month, with 6,070 incidents. Cloud providers led in the total number of outages (4,723), followed closely by developer tools (4,589).

Besides volume, AI providers moved firmly into the production infrastructure layer with LLM outages resulting in disruption across EdTech, developer tooling, customer support, and communication tools. Automation created new failure modes of its own: Google Cloud's May suspension of Railway's account resulted in almost all their workloads being unavailable. Edge and CDN incidents kept multiplying downstream, IAM remained a login bottleneck for entire product stacks, and Canvas's May security incident took classrooms offline during exam season.

This report breaks down H1 2026 by layer - cloud, edge and DNS, IAM, developer tools, collaboration, AI, payments, observability, and EdTech - with the major incidents, category trends, and cascade patterns based on the data.

Introduction​

On July 16, 2026, AWS experienced a disruption in its CloudFront service, which affected a large number of websites and applications. The outage was caused by a configuration loading failure in CloudFront's VPC Origins feature. This was AWS's most widely-felt outage after last year's outage on October 20th, which caused widespread damage.

Executive Summary​

Hashicorp's co-founder Mitchell Hashimoto decided to pull out his Ghostty project from GitHub in April 2026 due to GitHub's reliability issues. He did this after 18 years of using GitHub, saying that GitHub "is no longer a place for serious work".

GitHub has experienced a significant decline in reliability over the past 6 months, and Hashimoto is not alone in expressing this sentiment. In the past 12 months, GitHub has experienced 48 major outages, including outages in GitHub Actions, Copilot, Pull Requests, and core Git operations.

This article analyzes in depth GitHub's outage history between May 2025 and April 2026, the possible causes, and the impact on developers and businesses. IncidentHub has monitored every GitHub outage for the past 12 months and beyond - read on to find out what the data reveals.

Introduction​

Amazon Web Services remains one of the most popular cloud providers, with 200+ services in 39 regions across the world. Like all providers, they have their share of outages.

In 2025, IncidentHub detected 38 AWS outages, of which the one on October 20th had the most widespread impact affecting hundreds of SaaS providers simultaneously. Payments were disrupted, students lost access to classrooms, developer tooling degraded, and some IT teams experienced alerting gaps.

In this post we look at the reliability of AWS in 2025 based on their own publicly available status page data aggregated by IncidentHub, with a deeper analysis of the cascading impact of the October 20th outage.

Cloud Outages and Their Impact​

Cloud outages in 2025 ranged from minor ones affecting some sections of users, to major ones affecting hundreds or thousands of users. Services like Cloudflare and AWS on which many other services depend experienced outages that affected many due to the cascading effect.

Let's look at some of the major cloud outages in 2025.

Introduction​

A newer and expanded version of this article is available here.

Last updated on August 8, 2025.

Incident updates on the public status pages of your SaaS vendors and cloud providers are often the first indication that they might have an outage. Providers also post updates about upcoming and ongoing maintenance on their status pages. Monitoring your SaaS and cloud status pages to detect downtime becomes crucial to your business operations. This article will guide you through the process of effectively monitoring such status pages.

There are two ways to monitor multiple status pages:

• The manual process.
• Using a status page aggregator like IncidentHub.

If you are using the second option, which is the recommended approach, you can skip directly to the section on Use a Status Page Aggregator Tool.

In either case you will need to identify your cloud providers and locate their public status pages first.

Chances are, most of your third-party cloud and SaaS dependencies are globally distributed and have many regions of operation. Chances are, your applications use a subset of a cloud or SaaS service. If you are monitoring such a service, why should you receive alerts for all regions or every single component in the service?

E.g. if you use Digital Ocean, you might be using Kubernetes in their US locations (NYC and SFO). You would want to know only when there is an outage in one of these locations. Digital Ocean's status page gives you the option to subscribe to outages across the board - it’s all or nothing. This is the case with most services with a few exceptions.

Choosing Specific Components to Monitor​

You can now choose which components/regions you wish to monitor in IncidentHub. Let us continue with our Digital Ocean example.

You can choose to monitor all components:

Why should you monitor your third-party Cloud and SaaS vendors if you are in SRE/Ops?

As part of an SRE team, your primary responsibility is ensuring the reliability of your applications. What makes you responsible for monitoring services that you don't even manage? Third-party services are just like yours - with SLAs. And outages happen, affecting you as well as many others who depend on them.

It's a no-brainer that you should know when such outages happen to be on top of things if/when it affects your running applications.

Most of your third party dependencies will have a public status page or a Twitter account where they publish updates on their outages. Here are some seemingly easy ways to monitor these pages

• Subscribe to the RSS feed of these pages
• Follow the Twitter account
• Sign up for Slack, Email, SMS notifications on the status page itself if the page supports these