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
• Methodology and Coverage
• Timeline of the Outage
• Impact and Root Cause
  • An Ordering Problem
  • Services Affected
  • The Fallback Change
• Railway's Routing - Two 404 Outages in 2026
• The Recovery
• What Railway Says Comes Next
• What This Means for Monitoring Your Cloud Providers
  • Checking Only for 5xx Errors
  • Watching Error Rates Inside Your Own Service
  • Leaving Private Networking Unchecked
  • Alert Thresholds That Are Too High for Short Outages
• Conclusion
• FAQ

Methodology and Coverage​

This summary draws on the following sources, all fetched on October 3, 2026:

• Railway's incident report on its blog, written by Angelo Saraceno, for the cause, the internal timeline and the remediation list.
• Railway's status page incident report, for the two public updates and the affected components.
• Railway's status history page, for Railway's earlier 2026 incidents.
• Railway's regions documentation, which lists four deploy regions: US West Metal (California), US East Metal (Virginia), EU West Metal (Amsterdam) and Southeast Asia Metal (Singapore).
• Railway's May 19, 2026 incident report, for the vendor's own recent history.
• IncidentHub's own record of Railway's status page and user reports.

Note: The internal times in the timeline (merge, rollout, schema update, detection) come only from Railway's report.

Timeline of the Outage​

Rows without a source tag (e.g. [Railway status page]) come from Railway's blog writeup.

Impact window (from Railway incident report): about 07:35 UTC to about 07:40 UTC, about 5 m, from the routing service rollout to the schema update being applied. From the first failures to Resolved on the status page was about 42 m.

Sources:

• Railway: Incident Report: September 30, 2026: Domain Routing Disruption
• Railway status page: Domain routing disruption (IFBXJTGG)
• Railway status history
• IncidentHub's own record of the Railway status page

Impact and Root Cause​

Railway was preparing to ship an authentication layer that lets customers put a login in front of their services. According to Railway, that feature needed a modified data type in the database that stores routing data, along with a new version of the routing service that reads the new table format. The two pieces deploy through separate pipelines.

An Ordering Problem​

The incident report says that due to a race condition in the configuration, the pipelines did not follow the correct order of deployment, and both ran in parallel.

The correct order should have been:

1. Schema update rollout
2. Routing service deployment

Although the system recovered by itself as the new database schema completed rolling out, users saw errors until that happened.

From the report:

The schema update runs as a migration job within one system, and the routing service is built by another. When the routing service was part of a larger monolith (aka the non-distributed control plane), a single pipeline enforced that order. After we split it out, into the distributed control plane to add additional resiliency, the entire system was parallelized.

The failed lookups turned into a platform-wide 404 because of how Railway's origin proxies handle a failed lookup. Railway's report says the origin proxies ask the routing service which workload a request for a domain should go to, and treat an answer of "no routes" as a domain that does not exist. During the incident the origin proxies handled a failed lookup the same way. Railway also says the change itself had modified the origin proxies' fallback behavior, so the origin proxies could not fall back to the last route they had seen for that domain, and Railway names this as the reason for the widespread impact. The same routing service resolves private network DNS, which is why some private networking lookups failed in the same window.

Services Affected​

• New connections to custom domains and *.up.railway.app domains, which returned HTTP 404 in all regions.
• Some private networking lookups between services.

What kept working, on Railway's word:

• Running workloads, which kept running throughout. Railway says no data was lost.
• Existing connections, which were not disrupted.
• The fix itself needed no rollback. Routing recovered on the next retry once the schema update finished.

The Fallback Change​

Railway says it ships features disabled, after extensive testing in development and staging, and this change was tested in staging before the merge. However, the part of the change that altered the origin proxies' fallback behavior was evidently live in production during the race, because Railway's own report gives it as the reason the origin proxies could not fall back to the last known route. The report does not say whether that part was meant to be gated with the rest of the feature.

The fallback change probably decided the size of this outage.

Railway's Routing - Two 404 Outages in 2026​

Railway's report says the distributed control plane was "introduced recently" so that routing keeps working during a major cloud outage. Four months earlier, on May 19, 2026, Railway lost its Google Cloud-hosted infrastructure for roughly eight hours after Google Cloud suspended its production account. In that report Railway explained that its edge proxies cached routing tables from a network control plane hosted in Google Cloud. Once the cache expired, workloads on Railway Metal and AWS that were still running began returning 404 errors because the edge could no longer resolve routes, and Railway said it was working on removing that dependency.

Railway's status history lists other edge and domain incidents earlier in 2026, among them "A subset of domains are failing with a 503 error page" on February 21, "Elevated error rates on Edge Network" on March 1 (whose resolution update describes elevated 503 rates across all regions), and "Request timeouts and Service Unavailable responses on Edge Network" on March 24 to 25. The titles alone do not show a shared cause.

IncidentHub recorded 160 Railway incidents between January 1 and September 30, 2026.

The Recovery​

Railway did not roll back. The routing service kept retrying its lookups, and once the schema update was applied at about 07:40 UTC the next retry succeeded and routing resumed. Railway confirmed full recovery at 07:47 UTC.

What Railway Says Comes Next​

From Railway's report:

• Serial ordering of migration rollouts. Railway is unifying the deployment pipeline so that deploy order and blast radius are checked before merge, as they were when the system was a monolith.
• Schema validation before go-live. Each rollout validates the schema version it was written against, and the service refuses to go live until the matching database schema is in place.
• Shard-based rollouts per region. Railway says it already uses shard-based rollouts for most other systems and will add them to the distributed control plane to isolate impact.

Railway says that every major outage stops work on the affected system until guardrails ship, followed by a root cause analysis and a review of operating procedures. Railway says it has tested the new procedure and confirmed that it mitigates the root cause.

What This Means for Monitoring Your Cloud Providers​

If your team runs services on Railway, this outage is a useful test of your own monitoring, because it was short, it returned an unexpected status code, and it was over before the vendor said anything. Most of the checks below apply to any platform you deploy on.

Checking Only for 5xx Errors​

A check that alerts on 5xx errors or timeouts would have stayed quiet, because Railway's origin proxies answered every new connection with a 404. Ideally, point an external probe at each of your Railway-hosted domains, expect a 200 (or the exact response you know is correct), and alert on anything else.

Watching Error Rates Inside Your Own Service​

Your internal telemetry would not have shown these 404s. The origin proxies responded with 404 on their own, so the requests never reached your service, and what your dashboards would most likely have shown was a drop in traffic. Add an alert on a sudden fall in request volume, and run at least one probe from outside Railway.

Leaving Private Networking Unchecked​

Some private networking lookups between services failed in the same window, and a probe against your public domain does not exercise that path. Add a health endpoint that makes a call to another of your services over private networking and fails if that call fails.

Alert Thresholds That Are Too High for Short Outages​

A probe that runs every five minutes and needs two failures in a row before it alerts can miss an outage of this length. However, this needs to be tuned to each service's needs. If you set a higher threshold for alerts, you might miss short outages. If you set a lower threshold, you might get false positives.

Conclusion​

Railway-hosted domains returned 404 to new connections in all four regions for about five minutes on September 30, 2026, between roughly 07:35 and 07:40 UTC, according to Railway's own report. Railway attributes the outage to a routing service build that went live before the schema migration it depended on, made possible by pipelines that ran the two in parallel, and made platform-wide by a change to how the origin proxies fall back when a lookup fails. The outage ended before Railway's status page said anything, which is the reverse of the long tail seen in longer incidents, where "resolved" appears while some customers are still down.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by Railway or any of the services and vendors mentioned in this article.

This article was first published on the IncidentHub blog.

You might also like:

• GitHub Outages 2025 - 2026: Reliability Analysis and Outage History
• H1 2026 Cloud and SaaS Reliability Report
• The August 13, 2026 Namecheap Outage
• The August 6, 2026 GitHub Actions Outage: Queued Jobs, Throttled Webhooks, Impact Lasting 10 Hours

IncidentHub tracked 30,246 outages across 1,082 providers between January and June 2026. Dependency risk is a major factor when your business depends on third-party services. A vendor outage monitor and status page aggregator can help you stay on top of which vendors are down, and which are up.

UptimeRobot announced in July 2026 that it had acquired the status page aggregator IsDown. IsDown's own announcement had said earlier that the product, name, team, and prices would stay the same, with billing moving to UptimeRobot. If you are looking at other options, here is a list of some tools that do the same job.

Sites like Downdetector work differently, using reports from users rather than official status pages, so they aren't in this list.

Every feature and plan below was taken from each product's own website on September 21, 2026, named in each section. Products change, so please check the named sites before you decide.

• Introduction
• How This List Was Created
• What is IsDown
  • Features
  • Pricing
• IsDown Alternatives
  • IncidentHub
    • Features
    • Pricing
  • Statusfield
    • Features
    • Pricing
  • StatusStack
    • Features
    • Pricing
  • EagleStatus
    • Features
    • Pricing
  • StatusPulse.io
    • Features
    • Pricing
  • Outagely
    • Features
    • Pricing
• Mistakes to Avoid When Switching from IsDown
  • Choosing by catalog size
  • Not writing down your current setup
  • Checking integrations on the website instead of on your plan
  • Forgetting outages that never reach public status pages
  • Not deciding how much history you need
  • Forgetting custom integrations
  • Turning everything on at once
  • Switching before the new tool has seen a real incident
  • Forgetting your status pages
• Conclusion
• FAQ

How This List Was Created​

We looked at tools that watch official vendor status pages, and either send alerts or display the overall status on a unified status page, or both. The feature lists come from each tool's own website. Each tool has a screenshot where applicable, captured on September 21, 2026.

What is IsDown​

IsDown watches the status pages of other companies' services and alerts you when one of them has an outage. It tracks 6,320+ vendors. Since June 2026 it has been owned by UptimeRobot.

Screenshot: IsDown landing page, captured on September 21, 2026.

Features​

From the IsDown website, fetched on September 21, 2026:

• Status page aggregation across 6,320+ vendors
• Component filtering and a maintenance feed
• Early outage detection
• Status pages: public, private, and authenticated, with custom domains and branding removal
• Uptime monitoring with SSL and keyword checks, from multiple locations (every 3 minutes; every 1 minute on the Business plan)
• Private status ingestion for Zendesk and Microsoft 365 (Auth0 listed as "Soon")
• Alerts by email, Slack, Microsoft Teams, Google Chat, Discord, and SMS
• Integrations: Datadog, Grafana, Zendesk, Freshservice, ServiceNow, PagerDuty, Opsgenie, FireHydrant, Rootly, Incident.io, Squadcast, Better Stack, StatusHub, Statuspage.io, Zapier, webhooks
• API access and an MCP server
• Multiple admin users, count depending on the plan
• SSO for admin dashboard and for status page access
• Historical data - 6, 12, 24 months depending on the plan

Pricing​

Plans: Starter, Pro, Premium, Business, MSP, and Enterprise. 14-day no credit card free trial.

Screenshot: IsDown pricing, captured on September 21, 2026.

IsDown Alternatives​

IncidentHub​

IncidentHub monitors the official status pages of third-party cloud and SaaS services and sends alerts when a service has an outage.

Screenshot: IncidentHub, captured on September 21, 2026.

Features​

• 1,125+ services as of this writing
• Unlimited notifications
• Subscribe to individual components, e.g., GitHub Actions rather than all of GitHub
• Turn off maintenance alerts, and choose which alerts in the incident lifecycle to receive (start, updates, and resolution)
• Maintenance feed and maintenance reminders
• Private status ingestion for Microsoft 365, Microsoft Azure, and Infor CloudSuite using official APIs
• Alerts and integrations: Slack, Discord, email, webhooks, Microsoft Teams, PagerDuty, Zendesk, BoldDesk, Freshdesk, and Atlassian Jira Service Management
• Customizable public status page, affected components and history view, password protection, branding removal, and hosting on your own domain
• For MSPs - per-client status pages in a single account: up to 50 on the Multi-Client plan
• Choose which components from each service appear on the public status page as top-level cards (Multi-Client plan)
• Separate teams, each with its own monitors, alerts, and status page to route different alert groups to different alert channels (Business plan)
• Historical availability data and incident timeline per service - 30 and 90 days depending on the plan

Pricing​

Free, Starter, Pro, Multi-Client, Business. 14-day no credit card free trial.

Statusfield​

Statusfield tracks the status pages of third-party services and your own sites.

Screenshot: Statusfield, captured on September 21, 2026.

Features​

From the Statusfield website, fetched on September 21, 2026:

• 7,000+ services tracked
• Unlimited notifications
• Subscribe to individual components
• Route alerts by severity and type to different alert channels
• Alerts by email, Slack, Microsoft Teams, Discord, Telegram, PagerDuty, Datadog, webhooks
• API, MCP server, and RSS feed
• Uptime, SSL, and domain expiration checks
• Status boards you can share, with password or invite-only access, email subscribers, your logo, and custom URL
• A board per client for MSPs
• Monitoring evidence export for SOC 2 and ISO 27001 audits (Team plan)

Pricing​

Basic, Starter, Pro, Team. 30-day no credit card free trial.

Screenshot: Statusfield pricing, captured on September 21, 2026.

StatusStack​

StatusStack monitors third-party services' status in real-time.

Screenshot: StatusStack, captured on September 21, 2026.

Features​

From the StatusStack website, fetched on September 21, 2026:

• 11,000+ monitored sources
• Unlimited team members (Pro plan)
• Website and API monitoring
• Maintenance notifications
• Alerts on email, Slack, Microsoft Teams, webhook, Discord, SMS, Telegram, PagerDuty, Better Stack, Google Chat, Zendesk, Freshdesk, Freshservice, Jira
• Unlimited historical data
• "Stacks": grouped dashboards of the services you choose
• ConnectWise PSA integration (MSP plan)
• Scheduled per-client SLA reports (MSP plan)
• Severity-based, service-specific, and time-based alert routing
• TV board display
• Custom branding, subscriber notifications, custom domains, auth protection for status pages
• Team members and role-based access

Pricing​

Free, Pro, MSP. 14-day no credit card free trial.

Screenshot: StatusStack pricing, captured on September 21, 2026.

EagleStatus​

EagleStatus monitors cloud services from a single dashboard.

Screenshot: EagleStatus, captured on September 21, 2026.

Features​

From the EagleStatus website, fetched on September 21, 2026:

• 1,700+ services
• Multiple dashboards and users on higher plans
• Filtering by component and region
• Alerts on Slack, Discord, Microsoft Teams, webhook, email
• API access, SSO, and custom integrations by contacting their team

Pricing​

Free, Basic, Pro, Premium.

Screenshot: EagleStatus pricing, captured on September 21, 2026.

StatusPulse.io​

StatusPulse tracks the operational statuses of critical services and sends you real-time updates of outages and disruptions.

Screenshot: StatusPulse, captured on September 21, 2026.

Features​

From the StatusPulse website, fetched on September 21, 2026:

• 4,158 vendors tracked
• Alerts on Slack, Microsoft Teams, Discord, Freshservice, FireHydrant, email
• Service uptime reports
• Uptime and SSL monitoring

Pricing​

Free, Starter, Pro, Enterprise.

Screenshot: StatusPulse pricing, captured on September 21, 2026.

Outagely​

Outagely tracks SaaS vendor outages in one view, for support, IT, and engineering teams.

Screenshot: Outagely, captured on September 21, 2026.

Features​

From the Outagely website, fetched on September 21, 2026:

• 148 vendors tracked (mentioned on their homepage)
• Alerts on Slack, Microsoft Teams, Google Chat, Discord, Telegram, webhooks
• Service states normalized across vendors
• One dashboard for cloud, SaaS, and platform dependencies
• Incident timeline showing changes and recoveries
• Every entry links back to the vendor's own status page
• Daily briefs and historical patterns for reporting

Pricing​

Not published on their website.

Mistakes to Avoid When Switching from IsDown​

Switching tools can seem like a small project in itself. However, most of the risk can be in details you only notice after the old tool is gone. Check these before you begin.

Choosing by catalog size​

The number of vendors a tool tracks tells you little on its own. What matters is whether the vendors your team depends on are covered, and whether you can pick the components or regions you use, e.g., GitHub Actions rather than all of GitHub. Write down your list and search each tool's catalog for every item on it. If it's not available in the target tool, check with the tool's team how soon they can add it.

Not writing down your current setup​

Before you switch, note which vendors you monitor, which components you filter on, and which alerts go to which channel. Rebuilding this from memory in a new tool can lead to missed or noisy alerts, or an incomplete status page.

Checking integrations on the website instead of on your plan​

An integrations page lists everything a tool supports. The plan you buy may not include all of it. Check the pricing page for the plan you will actually pay for - the one that will meet all your needs.

Forgetting outages that never reach public status pages​

Microsoft 365 and Azure do not post incidents that affect only some tenants on their public status pages. If those matter to you, check whether the tool can read your Microsoft 365 or Azure tenant's service health, and on which plan.

Not deciding how much history you need​

If you use past incidents for vendor reviews, SLA claims, or client reports, check how much history the new tool keeps on your plan.

Forgetting custom integrations​

If you use any custom integrations with an API or webhooks to build your own dashboards, or to push outage data to your workflows, check whether the new tool can do the same. Even if it does, the data format will likely be different.

Turning everything on at once​

Every vendor and every update switched on from day one is a fast way to get the alert channel muted. Start with component filters, decide whether you want maintenance alerts, and add vendors one by one.

Switching before the new tool has seen a real incident​

Run the new tool next to your current tool until it has caught at least one real vendor incident, and check that the alert reached the right people. Then go ahead with the switch.

Forgetting your status pages​

If staff or clients use a status page from your current tool, that link will change. Set up the new page first, then tell them where it has moved.

Conclusion​

The tools above all track vendor outages from one place, but they differ in:

• How many vendors they cover
• Where they send alerts
• Alert routing and filtering critera
• What else they include, e.g., uptime monitoring or per-client status pages
• Which tools they integrate with
• Customizability of status pages
• Tenant-specific health data ingestion

Most of the tools above have a free plan or a free trial, so you can test with your own vendors and existing workflows before you pay.

If you want to try IncidentHub, you can start a 14-day free trial, no credit card needed.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders.

Features and plans were taken from each vendor's own website on September 21, 2026 and may have changed since.

This article was first published on the IncidentHub blog.

You might also like:

• How to Monitor SaaS Status in 2026 : A Complete Guide
• Vendor Outage Monitoring for MSPs
• Top 6 Reasons Why You Need a Status Page Aggregator

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
• Methodology and Coverage
• Timeline of the Outage
• Impact and Root Cause
  • What Was Taken Offline and Why
  • Services Affected
  • Namecheap Was Not the Only Affected Provider in Phoenix
• The Recovery
• What Namecheap Says Comes Next
• Conclusion
• FAQ

Methodology and Coverage​

This write-up is based on Namecheap's own emergency maintenance post, its retrospective blog post of August 14, and the public statement posted by Hillan Klein, CEO of Namecheap, on August 13. Facility-level detail comes from the phoenixNAP outage report, which republished the datacenter operator's (RadiusDC) customer bulletins verbatim, with timestamps, throughout the day.

Important Note: phoenixNAP is a separate company that publishes its own status page, and on the same day it published an outage report for higher ambient temperature in the Phoenix DC naming RadiusDC as its datacenter provider. Namecheap has never linked to that incident, referenced phoenixNAP’s outage, or named PHX-01. The two are connected here by common data points - same day, same city, same operator named, same chiller failure attributed to the same storms. This is not a documented fact but an inference, and it is treated as one throughout this article. phoenixNAP’s incident is used as a separate data point that happens to carry RadiusDC’s customer bulletins verbatim; it is not treated as a record of Namecheap’s outage. Namecheap has stated explicitly that phoenixNAP is not its datacenter operator, however, some earlier posts on X and Namecheap's status page post incorrectly referred to it.

Timeline of the Outage​

phoenixNAP rows are marked [phoenixNAP]. They describe a different company’s incident and are included for the RadiusDC bulletins they carry, not as Namecheap events.

Impact window (Namecheap status page): Aug 13 12:35 UTC to Aug 14 17:00 UTC, about 28 h 25 m from the first emergency post to the resolve.

Sources:

• Namecheap status page report. Note that the Namecheap status page report is gone, and the archived version is a partial snapshot, but IncidentHub recorded it when it was available, including the resolution time.
• phoenixNAP status page report.

Impact and Root Cause​

The root cause was outside Namecheap's control. Namecheap says only that cooling systems failed at the RadiusDC: Phoenix datacenter - Namecheap's largest - due to a major storm. The additional data comes from a RadiusDC customer bulletin, which reaches the public record through phoenixNAP’s status page. The bulletin attributes elevated temperatures at a Phoenix datacenter to multiple utility events caused by overnight storms in the Phoenix area. The chillers went down with the utility disturbance.

Namecheap's blog describes RadiusDC: Phoenix as a Tier 3 datacenter designed with a high level of redundancy, and calls the incident unusual and unprecedented in its 25-year history.

What Was Taken Offline and Why​

The servers were switched off deliberately. Klein's statement puts the number at more than 5,000 servers, and describes the shutdown as a deliberate decision taken to protect customer infrastructure from overheating and longer-term damage. The shutdown decision was probably a reasonable call. The cost was that the outage lasted as long as the cooling did, plus the restoration.

Services Affected​

Per the first status post and the CEO statement:

• Namecheap.com and the account dashboard.
• Shared, VPS and Dedicated Hosting, including hosting panel access.
• EasyWP - EasyWP.com, the Dashboard, and client websites.
• DNS management. DNS zone resolution stayed up.
• Private Email, Shared Hosting mailboxes, Free Email Forwarding and Domain Privacy email forwarding.
• URL Redirect management on BasicDNS and PremiumDNS. Redirects continued to resolve.
• Hosting operations - activations, renewals, plan changes - processed with a delay. The blog adds that some billing operations were unavailable after the processing system was taken offline.
• The support helpdesk, live chat and email, with Microsoft Teams accounts offered as a fallback.

The Auctions API and the iOS and Android auction applications were listed as continuing to operate normally.

On email, Namecheap's position from the first post onward was that delivery would be delayed but messages were not expected to be lost, on the basis that sending servers retry. That is correct as a general description of SMTP behavior. However, retry windows are set by the sending server, not the receiving one. Namecheap has not published anything to suggest that mail was in fact lost.

Namecheap Was Not the Only Affected Provider in Phoenix​

phoenixNAP published its own cooling-related outage report across the same window, naming RadiusDC as its provider.

Spaceship, Namecheap's web services platform, published its own outage post naming the same RadiusDC: Phoenix facility. Spaceship reported Shared and VPS hosting, EasyWP, email forwarding and Spacemail affected, although Spaceship.com itself stayed online throughout, which Namecheap.com did not.

Hosting.com warned first of elevated ambient temperatures and possible equipment reboots, then later reported an active service outage with impacted servers unavailable, which appears to be related to the same incident.

Namecheap and Spaceship both name RadiusDC: Phoenix, so those two are the same facility on the vendors’ own word. phoenixNAP and Hosting.com are inferred to be the same building from matching dates, city, and failure mode, although Hosting.com does not name RadiusDC.

The Recovery​

Restoration was staged, and Namecheap said so in advance at 18:30 UTC: physical network devices, then virtual network devices, then customer services. The blog gives the reasoning afterwards, that hosting and email sit on servers, networks, storage and databases that have to come back in order rather than all at once.

phoenixNAP’s own incident shows a tail longer than its all-clear suggested: it declared all systems restored at 06:10 UTC on August 14, then opened a fresh incident a little over four hours later for Cloud Object Storage, which its status page attributes to the same cooling issue.

The pattern is similar to many outage recoveries IncidentHub covers. Complete recovery takes longer and a customer affected by the long tail reads "fully back online" while their own site is still down.

What Namecheap Says Comes Next​

From the blog post:

• A review of the incident, with results to be shared publicly.
• More redundancy across its datacenters, which also include Europe and Asia.
• A commitment to be transparent about what is learned.

Conclusion​

Namecheap's outage ran from an emergency post at 12:35 UTC on August 13 to a resolve at 17:00 UTC on August 14, about 28 and a half hours. Namecheap attributes it to a cooling system failure at RadiusDC's Phoenix datacenter following a major storm, and powered down more than 5,000 servers to prevent overheating damage. The mechanism behind the cooling failure - utility disturbances affecting the chillers - comes from a RadiusDC bulletin published on phoenixNAP's status page, not from Namecheap.

DNS zone resolution survived here because it sat outside the failure domain, whereas DNS management did not. Namecheap's blog says the Phoenix facility hosts some essential Namecheap operations, and the list of what broke suggests those operations sit under most of the product line. Namecheap and Spaceship lost services in the same building on the same day.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by Namecheap, Spaceship, RadiusDC, phoenixNAP or any of the services and vendors mentioned in this article.

This article was first published on the IncidentHub blog.

You might also like:

• H1 2026 Cloud and SaaS Reliability Report
• The August 6, 2026 GitHub Actions Outage

Introduction​

On August 6, 2026, GitHub opened an incident for degraded Actions performance at 15:22 UTC. Within about twenty minutes, Actions availability was listed as degraded, workflow runs were failing to start or failing partway through, and the Actions REST API was returning errors. Pages was pulled into the same incident shortly afterwards. The status page marked Actions and Pages as mitigated at 00:05 UTC on August 7, and closed the incident at 02:04 UTC.

What the live updates showed at the time was a multi-hour recovery through constrained capacity, throttled webhooks, invalid job assignment, and self-hosted runner problems - followed by cleanup work that continued after the incident was marked resolved. GitHub added a root cause analysis to the incident page on 11 August 2026, appended to the 7 August resolve post rather than as a separate update.

• Introduction
• Methodology and Coverage
• Timeline of the Outage
• Impact and Root Cause
• Preventing Future Actions Outages
• GitHub Actions - A Pattern of Failure
• Conclusion
• FAQ

Methodology and Coverage​

This write-up is based on GitHub's own incident page, with customer-facing detail from GitHub's community incident thread. Resolved timestamps below are status page state. IncidentHub monitors GitHub status updates in real time and the aggregate charts in this post are based on that data.

Timeline of the Outage​

Impact window (status page): Aug 6 15:22 UTC to Aug 7 02:04 UTC (about 10 h 42 m from first investigating post to resolve). Although the RCA notes that the impact window ended at 00:14 UTC, the overall impact continued as is evident from the live updates published previously until 02:04.

Mitigation called: Aug 7 00:05 UTC (about 8 h 43 m after the first investigating post).

Note: A separate Pages incident ("Incident with Pages - Deployment Lag") was opened at 15:03 UTC and marked resolved at 16:22 UTC on August 6. The Actions incident above still listed Pages as degraded after that separate incident closed.

Source: GitHub Status, Incident with Actions, August 6-7, 2026

Impact and Root Cause​

GitHub named Actions and Pages as the affected components on the incident. The live updates also named Copilot code review, Copilot coding agent, hosted runners, self-hosted runners, webhook deliveries, and migrations using GitHub Enterprise Importer.

What customers saw, in GitHub's words:

• Workflow runs failing to start, failing partway through, staying queued, or timing out.
• Actions REST API errors and unexpected rate limiting.
• Webhook throughput cut during recovery - down to about 15% at one point - so many push and pull request events did not start workflows.
• Runners assigned jobs that were no longer valid, and runners stuck retrying unavailable jobs.
• Self-hosted runner registration errors or rate limiting.
• Pages degraded availability and performance.
• GitHub Enterprise Importer migrations failed, then paused as a mitigation.

At 15:45 UTC, GitHub said engineers had identified the source of the disruption, although the public updates did not name it. On 11 August 2026, GitHub published a root cause analysis on the incident page. It sits on the 7 August resolve post, not as a separately timestamped update.

Impact window (RCA): 15:05–00:14 UTC on August 6–7. GitHub-hosted and self-hosted runners were both affected. At peak, 71% of workflow runs saw infrastructure failures, and 75% of the remainder were delayed by more than 5 minutes.

Note: The RCA's impact window starts at 15:05 UTC, which is 17 minutes before the first public investigating post at 15:22 UTC. The status page marked the incident resolved at 02:04 UTC on August 7.

The failure had two stages. A routine deployment to an internal Actions service - the one that processes events and generates jobs - exposed an existing capacity and concurrency weakness. As pods were replaced, remaining capacity saturated, services crashed, and the impact cascaded across multiple clusters and downstream services. GitHub said those services recovered at 17:00 UTC after expanding capacity, throttling webhook-triggered work, and raising processing capacity for the backlog.

The longer tail came next. Work piled up in the job-assignment path, and a latent bug let runners take jobs that were no longer valid and then retry them indefinitely instead of picking up valid work. GitHub mitigated that by stopping repeated attempts on invalid jobs, which let the queues drain.

Some cleanup was still customer-visible after that. A mitigation deployed during the incident inadvertently left some Actions Runner Controller (ARC) runners offline until manually recovered; GitHub rolled that change back and said automatic recovery is coming in upcoming Runner and ARC releases. Some jobs created during the incident were left stuck and could not be retried or cancelled; GitHub pointed customers to CLI and UI workarounds in the community thread. GitHub's 02:03 UTC update also said some push and pull request trigger events were not processed during the incident and cannot be replayed automatically - customers may need to push a new commit, update the pull request, or re-run the workflow. Reports in the same thread show the gap between resolve and recovery: users had workflow runs stuck in Queued after the incident was marked resolved, with cancel and force-cancel failing.

Other services which depend on Actions failed to push production deployments:

• Commercetools reported a failure in pushing deployments to production because of the Actions outage.
• WordPress VIP reported deployment issues arising from the same Actions outage.

Preventing Future Actions Outages​

GitHub noted in their RCA that they are taking measures to prevent such occurrences in the future:

• Improvements to deployment and capacity safeguards for the affected services
• Strengthening monitoring for the conditions preceding the incident
• Improving the resiliency and recovery of queued work and runner assignments
• Adding automatic recovery for self-hosted runners affected by similar failure conditions.

They also note that they are undertaking measures to reduce the risk of cascading failures and accelerate recovery during large-scale Actions disruptions.

GitHub Actions - A Pattern of Failure​

Eight days earlier, on July 29, 2026, GitHub published a postmortem for a shorter Actions incident: from 14:51 to 15:28 UTC, an under-provisioned internal Actions service at a single infrastructure site ran out of memory under load, Actions API requests that waited synchronously on that service timed out, and about 2% of workflows were delayed. That incident had a named cause and a named mitigation - scale out the runner-administration service and raise the replica count.

GitHub Actions outages have seen a trend towards longer durations over the course of 2026.

IncidentHub's earlier reporting put Actions at the center of GitHub's reliability problem. In our May 2025 to April 2026 GitHub reliability report, Actions was the most affected service, with 57 outages in that window. In the H1 2026 reliability report, Actions remained the worst affected GitHub component, with 37 recorded incidents in the first half of the year.

Between Jan 1, 2026 and August 7, 2026, GitHub Actions had 48 recorded outages, with 26 of them major.

Note: numbers for August are till 7th August, 2026 only.

The trend for major outages is moving upward, although overall Actions related outages dipped in June 2026 and then increased in July 2026.

Note: numbers for August are till 7th August, 2026 only.

Conclusion​

GitHub's August 6 Actions incident ran from 15:22 UTC to a resolve post at 02:04 UTC on August 7. Pages, Copilot code review, Copilot coding agent, hosted and self-hosted runners, webhooks, and GitHub Enterprise Importer migrations were named along the way as being affected. Recovery metrics improved as the incident progressed, and mitigation was called just after midnight UTC.

GitHub published the root cause on 11 August 2026, four days after the incident closed - a routine deployment that exposed a capacity weakness, then a latent job-assignment bug that kept runners retrying invalid work. The RCA said a mitigation deployed during the incident had inadvertently left some ARC runners offline until manually recovered; GitHub rolled that change back. Customer reports of unreplayable triggers, stuck jobs, and workflows still Queued after resolve still matter: status page state and pipeline state are not the same thing.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by GitHub or any of the services and vendors mentioned in this article.

This article was first published on the IncidentHub blog.

You might also like:

• GitHub Outages 2025 - 2026: Reliability Analysis and Outage History
• H1 2026 Cloud and SaaS Reliability Report
• GitHub Reliability - Current Status

IncidentHub's latest product update includes a Multi-Client plan built specifically for MSPs and agencies with per-client status pages, service components as top-level objects on status pages, and support for more vendors (1125+ and counting).

• What's New in IncidentHub in July 2026?
• Per-Client Status Pages in a New Plan
• Service Components As Top-Level Objects in Status Pages
• New Services

Per-Client Status Pages in a New Plan​

MSPs and agencies usually monitor a specific catalog of vendors, whereas their clients use different subsets of that catalog. One client may run Xero, Microsoft Teams, and Azure; another may use MYOB, Slack, and Google Cloud. A single status page that lists everything is noise for each of them.

The Multi-Client plan is built to fulfill these needs. From one IncidentHub account you can create upto 50 public status pages. Each page is a filtered view of the services you already monitor - pick the subset for that client, brand it, and give them the link. Duplicate an existing page when the next client is mostly the same stack with a few swaps.

Technically this is not a second account and not Teams. You set up monitorinf for the full catalog once. Alert settings, components filters, and notification channels stay account-wide. Only the published page differs per client.

Setup steps are:

1. Monitor the vendors (and regions/components) you care about.
2. Create or duplicate a status page per client.
3. Under Services, select the subset for that page. Empty means show all monitored services.
4. White-label branding and, if needed, a custom domain per page.

Custom domain setup is not self-serve yet - email us and we configure it. Each page can also sit on its own {pageId}.incidenthub.net subdomain if you don't want a custom domain.

If you need independent monitors, channels, and alert configs per group inside one org, Teams on the Business plan remains the better fit. If you need one branded page per end-client with a shared monitor list underneath, Multi-Client is what you need. The docs cover both: per-client status pages and when not to use Teams.

For the longer rationale - what clients need during a vendor outage, hosted page vs webhook dashboard, and the limits - see Vendor Outage Monitoring for MSPs.

Service Components As Top-Level Objects in Status Pages​

Previously, a status page listed services as top-level cards. Components and regions still decided what counted as an outage for that service - if you monitored only certain components, unrelated incidents stayed out - but the page itself showed one row per service.

That is enough when the question is "is Xero up?" It is not enough when two clients (or two audiences) care about different slices of the same vendor. E.g. one page may need Cloudflare status for Oceania, another for North America, without showing the rest of Cloudflare as a single aggregate.

You can now put individual monitored components on a status page as separate top-level cards. E.g. different clients that use localizated components for the same provider: e.g. Cloudflare Oceania, Cloudflare North America, etc. depending on their location, can choose to see only the regional components on their status page.

You can choose this in the Services selector when you are creating or editing a status page on the Multi-Client plan: a full service, or first-level groups, or specific second-level components. This list is built from the components you monitor for that service.

Card titles follow the component hierarchy - e.g. Twilio - CONVERSATIONS, or Cloudflare - Durable Objects - Asia. Incidents and history on that card are scoped to the selected component(s).

A few boundaries worth stating:

• This is a status page presentation change. The maintenance widget and the affected components and history popup widgets on the status page are also affected if you choose components as top-level objects. Add/Edit monitoring, the dashboard outage and maintenance widgets, the availability dashboard, and alerts are unchanged.
• You cannot break a service into components on the page if you monitor that service as "all" in Add/Edit - the selector only offers a component breakdown when you monitor specific components.
• A page never shows both an aggregate service card and component cards for the same service at once.

If you leave the Services selection empty, the page still shows all monitored services - same default as before. You can always edit the page later to add components.

New Services​

We've added support for more vendors including ServiceNow, Azure DevOps, Intuit QuickBooks, N-able, Pax8, Sophos, SonicWall, Vultr, ThreatLocker, and xAI, to name a few. This brings up the total number of supported vendors to 1125+.

Keep watching this space for more updates to IncidentHub.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All the logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

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
• Methodology and Coverage
• Timeline of the Outage
• The Root Cause
• Cascade Impact on Other Services
  • Confirmed Cascade Events
  • Possible Cascade Events
• The Recovery Tail
• Three Infrastructure Failures in Nine Days
• Surviving Regional Network Outages
• Conclusion
• FAQ

Methodology and Coverage​

IncidentHub monitors all AWS services and regions using the AWS Health Dashboard, and separately tracks outages in downstream services that depend on them in real time.

Downstream impact is based on two factors:

• If the downstream service directly mentions AWS or Amazon Web Services in its own incident update, then it is a confirmed cascade event.
• If the downstream service does not mention AWS directly, but the time window coincides and the update names the same region, an upstream provider, or both, then we mark it as a possible cascade event.

Not all downstream providers explicitly mention AWS in their own incident updates, so the number of impacted services is likely higher than we see here.

The resolved timestamps below are also status page state, not customer impact. A provider resolving an incident at 21:28 UTC does not mean every customer was broken until 21:28 UTC, and a provider closing at 11:12 UTC does not prove nobody was.

Timeline of the Outage​

Initial impact window: 10:55-11:15 UTC (20 minutes), plus route reconvergence from 11:47 to 11:59 UTC.

Direct Connect at EqSe2, Westin Building Exchange, Seattle: 10:55-12:12 UTC (1 h 17 m). AWS noted that anyone holding a redundant path through a different Direct Connect location was not impacted by the event.

Note: AWS's first public update went up at 11:40 UTC, which is 45 minutes after impact began and 25 minutes after their own initial recovery. Engineers were pulled in automatically at 11:01 UTC, so internal detection was quick.

Source: AWS Health Dashboard, us-west-2 operational issue, July 24, 2026

The Root Cause​

AWS attributed the fault to the networking hardware that carries routing between the region and the Seattle Metro. Several mitigation paths were worked in parallel, and the first of them brought connectivity back at 11:15 UTC.

As the network settled after the mitigation, routes reconverged between 11:47 and 11:59 UTC, and connectivity flapped again for some customers while the new paths settled. The initial fix had worked, and the act of applying it produced a second, smaller window of impact.

AWS listed 10 affected services: AWS Direct Connect, AWS Global Accelerator, AWS Internet Connectivity, AWS IoT Core, AWS Site-to-Site VPN, Amazon API Gateway, Amazon Elastic Compute Cloud, Amazon Elastic Container Service, Amazon Elastic Load Balancing, and Amazon Virtual Private Cloud. That list is almost entirely the ingress and egress layer. Compute inside the region kept running as usual.

Cascade Impact on Other Services​

Confirmed Cascade Events​

Nine incidents at seven providers named AWS or Amazon Web Services in their own updates. The last column measures from 11:59 UTC, when AWS said routing was fully back.

StatusHub appears three times because they opened three separate incidents, all within five minutes of each other and all closed together.

Three of these cases are worth reading carefully:

• StatusHub opened three separate incidents and kept all three open until 14:10 UTC. Their updates through that stretch said while the platform itself was healthy, the incidents were being held open purely because the upstream AWS incident had not been closed yet. It is a reminder that status page state and service state are not the same thing.
• FortiSASE first filed the incident against AWS in EMEA, where Endpoint Management and Portal access were degraded for some customers. A later update noted that AWS had posted about US West (Oregon) but that the link to what they were seeing was still unconfirmed, and pointed at a spike on DownDetector as a secondary signal. They retitled the incident to cover Oregon and EMEA once the connection was confirmed.
• SendGrid is the counter-example. DNS health checks fired at around 11:09 UTC, and by 11:21 UTC their engineers had pulled the degraded region out of load balancing. Their update said customers should see no impact and that mail sending was unaffected.

Bambu Lab, whose cloud services sit behind consumer 3D printers, said they were shifting traffic to healthy regions where they could.

Possible Cascade Events​

Three more incidents at three providers line up with the outage on timing and either a region match or an unnamed upstream mention, but none of them named AWS. They are listed separately because the link is inferred rather than explicitly stated.

• TecAlliance TecDoc reported network issues for region-specific requests sent to US-West-2. The region matches but AWS is not named.
• Render posted a service disruption in Oregon and blamed an upstream provider without saying which one.
• RubyGems traced degraded service to an upstream provider during the same window, with no region named.

The Recovery Tail​

In the Azure West US outage the previous day, IncidentHub noted that recovery can trigger secondary problems and that none had been called out in the published incident reports. This time one provider wrote it up plainly.

NinjaOne posted their account at 15:38 UTC, well after AWS had finished. Their agents had tried to reach the backend during the outage, failed, and dropped into the backoff and retry path that exists specifically to stop an entire fleet hammering a recovering service at once. Reconnection was therefore slow and randomized by design. Separately, the service that processes device status could not keep up with the volume of agents changing state, and had to be scaled out before its metrics looked healthy again. They reported more than 150,000 devices coming back in the preceding hour, with the rest still working their way through.

SparkPost shows the same shape in a different layer. Their 17:32 UTC update described extra tuning to absorb the surge of mail that had piled up behind the AWS network fault, with full delivery expected to need another 80 to 90 minutes on top. Their earlier updates describe it: outbound delivery from the US West region was blocked by 11:53 UTC while they carried on accepting and queuing messages internally, delivery restarted at 12:08 UTC, and they were still working through the backlog at 13:16 UTC.

These are the aspects that are not evident in the upstream provider's impact reports - they are often felt by customers of downstream providers.

Three Infrastructure Failures in Nine Days​

If we set this alongside the two that came before it:

• July 16, 2026 - AWS CloudFront. Something in the fleet handling connections to private VPC origins stopped it loading updated configuration correctly. It was global in reach, roughly 3 h 33 m.
• July 23, 2026 - Microsoft Azure West US. A defect in how maintenance requests were translated pulled routes off a wider set of devices than the change had scoped, cutting off the datacenter from the wide-area network. Ingress and egress only, 4 h 57 m.
• July 24, 2026 - AWS us-west-2. Networking hardware on the path between the region and the Seattle Metro. Ingress and egress only, 20 minutes plus reconvergence impact.

Two of the three events broke at the same boundary - between a region and the wider network. In both cases compute, storage and databases inside the region were healthy but unreachable, which for a customer is indistinguishable from being down. AZ redundancy does not help in such cases.

Another pattern is invisible unless the downstream impact is checked - upstream duration cannot predict downstream duration. CloudFront was the longest of the three upstream events and the July 24 AWS event was by far the shortest, yet the July 24 cascade produced a long downstream tail.

Surviving Regional Network Outages​

• Know which of your vendors run in us-west-2, and which of them can fail over out of it. SendGrid could do it and activated it. Bambu Lab could do it but not completely. Most of the others did not mention failover at all.
• Plan for the secondary effects like reconvergence. AWS's own timeline has a second impact window after the fix, and your monitoring should not treat the first recovery signal as the end. However, this is difficult to plan for specifically and it's far better to monitor things yourself after your upstream provider has declared recovery. This is probably one of the reasons why downstream providers take longer to declare recovery in such cases.
• Plan for thundering herd issues before it happens. NinjaOne's agents had backoff and jitter and it still took hours.
• Audit your internal queue capacities and processing rates, and put knobs in place to either throttle or scale up capacity to avoid huge backlogs becoming bottlenecks.
• Monitor upstream cloud status and your SaaS dependencies in one place.

Conclusion​

The upstream fault at AWS was relatively small and quickly handled. Networking hardware between us-west-2 and the Seattle Metro failed at 10:55 UTC, AWS engineers were on it by 11:01 UTC, connectivity started returning at 11:15 UTC, and routing was fully back by 11:59 UTC. Traffic inside the region was unaffected.

Since a networking issue effectively means closing the gate, downstream providers have to wait for the gate to be opened again, or failover to other available regions, before they can start processing traffic. There were 9 confirmed downstream incidents across seven providers, plus three possible ones. None opened before AWS impact began at 10:55 UTC; 11 of the 12 were open before AWS's first public update at 11:40 UTC. The recovery tail lasted till 21:28 UTC on a short outage.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by AWS or any of the services and vendors mentioned in this article.

This article was first published on the IncidentHub blog.

You might also like:

• The July 2026 AWS CloudFront Outage: VPC Origins, Cascade Impact, and What Broke
• The July 23 2026 Azure West US Outage: IP Route Removal and Downstream Impact

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
• Methodology and Coverage
• Timeline of the Outage
• The Root Cause
• Cascade Impact on Other Services
• Downstream Recovery Lag
• Surviving Regional Azure Outages
• Conclusion
• FAQ

Methodology and Coverage​

IncidentHub monitors Microsoft Azure services via public status pages, and also tracks outages in downstream services that depend on them in real time.

Not every dependent SaaS will name Azure on its status page, so the cascade count is probably lower than the actual number. A regional networking failure that cuts ingress and egress still has a wide blast radius for any SaaS that has presence in that region.

Timeline of the Outage​

Impact window: 14:44-19:41 UTC (4 h 57 m).

Network restored: 18:26 UTC. Full service recovery declared at 19:41 UTC.

Source: Microsoft Azure Preliminary PIR - Issues connecting to resources in West US

The Root Cause​

A routine device maintenance activity required isolating specific network paths. Azure's process converts those requests into system-readable instructions and checks that at least one of two redundant paths remains healthy, with safety checks intended to keep the impact minimal.

A bug in the request conversion system incorrectly marked additional devices as part of the maintenance event. That removed a set of IP routes from more devices than intended - between the datacenter and the wide-area network - which disrupted traffic entering or exiting the entire West US region.

As the investigation progressed, it was discovered that the route removals originated from a datacenter in the West US region, and then the maintenance change was rolled back.

Impacted Azure and Microsoft services listed in the PIR included (and may not have been limited to) App Service, Application Gateway, Application Insights, Azure AD B2C, Azure AI Search, Azure AI Speech, Azure API Management, Azure Bastion, Azure Bot Service, Azure Cosmos DB, Azure Data Explorer, Azure Database for PostgreSQL, Azure Databricks, Azure Firewall, Azure Kubernetes Service (AKS), Azure Monitor, Azure Virtual Desktop, Azure VMware Solution, ExpressRoute Circuits, ExpressRoute Gateways, Log Analytics, Microsoft Graph, Microsoft Sentinel, Partner Center, Power BI Embedded, Virtual WAN, and VPN Gateway.

Unlike the July 16 CloudFront outage, this was a single-region networking failure rather than a global edge or control-plane issue. The pattern still rhymes with some other 2025-2026 automation and change-management failures: safety checks existed, but a bug somewhere in the workflow defeated them.

Cascade Impact on Other Services​

IncidentHub detected cascading outages in 19 downstream services that acknowledged impact related to the Azure West US incident. Since not all services named their upstream dependency, the actual number is likely higher.

Two operators stood out for how they published the failure:

• MeridianLink opened 5 separate incidents, each tied to the Azure outage and covering a different component or service in their product. This meant that they could notify their customers about the issue in a more granular way - each component separately.
• Nintex opened 2 incidents, likewise split by component, both caused by the Azure outage.

Most other providers opened a single incident for the same upstream event. Splitting by component can make internal ownership clearer, but it can also multiply status-page noise for customers unless they are watching specific components using a status page aggregator.

A few more examples of downstream impact:

• Datadog Integrations reported Azure metrics may be delayed because of a partial outage in the Azure Monitor API.
• Octopus Deploy named the upstream Azure outage directly. Among the known impacted services was the Octopus.com blog, so not every customer path was equally hit.
• MongoDB Cloud saw cluster connectivity issues for clusters hosted in Azure West US, then recovered after Azure rolled out mitigation. Issues included intra-node communication failures, nodes wrongly appearing down, and cluster modification delays.
• Wiz reported portal and API degradation across multiple US data centers. After Azure recovered, ingestion and detection were back, but it was possible that some customers could still see delays while processing caught up.
• Ellucian Cloud's Student Financial Success line of products went offline while Microsoft worked the West US fault, then brought it back when Azure recovered. This was an EdTech product, and we do not know the exact impact on educational institutions.

Downstream Recovery Lag​

Azure declared all its impacted services recovered at 19:41 UTC. Of the 19 downstream services IncidentHub tracked for this cascade, 16 still had open incidents well past that timestamp.

Recovery in downstream services during bigger infra outages can sometimes trigger secondary outages - from thundering herds, or from third-party rate limiting due to backed up queues getting processed. We did not observe any in incident reports in this case but that's not to say that none occurred. Also, once engineers are satisfied that an outage is mitigated, there is a period of monitoring to make sure things are absolutely ok.

The outage start times in the graph are from the status page announcements, and the huge lags from a few minutes to 3+ hours can indicate various things in the downstream services:

• Their own detection lag
• Announcement lag in the status page
• Actually delayed impact

Surviving Regional Azure Outages​

You cannot eliminate every dependency risk, but regional networking failures will make you think about your dependencies a bit more:

• Know which of your workloads and SaaS vendors pin critical paths to a single Azure region, especially if that region hosts your identity management SaaS or a vendor's control plane.
• Architect multi-region designs for mission-critical paths.
• Treat ingress/egress cloud components as first-class dependencies. An ingress/egress failure looks like "the app is down" even when compute inside the region is fine.
• Monitor upstream cloud status and your SaaS dependencies together using a status page aggregator like IncidentHub.
• Expect downstream status pages to lag. Plan your customer communications based on your own monitoring.

Conclusion​

The July 23 outage was nearly five hours long, confined to West US ingress and egress, and caused by a maintenance automation bug that removed more IP routes than intended. Azure restored the network by 18:26 UTC and declared full service recovery at 19:41 UTC. Many downstream SaaS vendors felt it for a longer period: incidents in 16 of the 19 dependent services IncidentHub tracked stayed open past Azure's recovery time, and acknowledgement lagged by minutes to hours.

If your stack or your vendors concentrate critical traffic in one region, a single regional failure in a critical component like networking can effectively cut off your application from your users.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by Microsoft, Azure, or any of the services and vendors mentioned in this article.

This article was first published on the IncidentHub blog.

You might also like:

• The July 2026 AWS CloudFront Outage: VPC Origins, Cascade Impact, and What Broke
• The July 24 2026 AWS us-west-2 Outage: Network Routing and a Long Recovery Tail

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
• Methodology
  • What We Monitor
  • How We Define an Outage
  • How We Measure Duration
  • Scope of This Report
  • Limitations
• H1 2026: Outage Numbers at a Glance
  • H1 2026 Outage Statistics
  • H1 2026 Outages by Category
• Cloud Provider Outages
  • Amazon Web Services (AWS)
  • Microsoft Azure
  • Google Cloud Platform (GCP)
  • Oracle Cloud Infrastructure (OCI)
• Edge, CDN and DNS Outages
  • Cloudflare
  • Fastly
  • Akamai
  • DNS Outages
• Identity and Access Management (IAM) Outages
  • The Authentication Dependency
• Developer Tools Outages
  • Source Control and Code Repositories
    • GitHub Outages
    • Other Source Control and Code Repositories
  • Package and Artifact Registries
• Communication and Collaboration Outages
  • Messaging Platforms
  • Document and Knowledge Platforms
  • Project Management Tools
• AI and LLM Tools Outages
  • AI Providers as a Key Infrastructure Dependency
  • Significant AI and LLM Incidents
    • Anthropic Fable 5 and Mythos 5 Suspension
• Payment Infrastructure Outages
• Observability, Monitoring and Incident Management Tools Outages
  • Observability and Monitoring
  • Incident Management
• EdTech Outages
  • Canvas (Instructure) - May 2026 Security-Related Outage
• H1 2026 Outage Patterns
  • Cascading Outages
  • Month-by-Month Trend (January - June 2026)
  • Duration Distribution by Month
  • Comparative View of Categories by Month
• Patterns in Distributed Infrastructure Outages
  • Global Propagation of Localized Trigger Points
  • Automated Policy Enforcement as a Risk
  • Control Plane Resilience Matters More
  • Recovery Can Trigger Secondary Outages
• Conclusion
• FAQ

Methodology​

What We Monitor​

• 1,125+ providers (as of this writing) monitored continuously: cloud infrastructure providers, SaaS platforms, developer tools, AI providers, payment processors, edtech platforms, observability tools, and communication services. A subset is used for this report.
• Monitoring is via public status pages (APIs, webhooks, RSS feeds). Private status monitoring (Microsoft Azure, Microsoft 365 etc) is also done but we did not use those numbers for this report.

How We Define an Outage​

• An outage is created when a provider updates their status page to indicate degraded performance, a minor issue, or a major issue. The terminology differs across providers.
• An outage is closed when the provider marks it as resolved.

How We Measure Duration​

• Duration is calculated from the provider's first incident acknowledgment timestamp to their resolution timestamp.
• Also, the provider-reported resolution may lag actual service restoration in some cases due to internal processes and checklists across their systems.

All timestamps are in UTC.

Scope of This Report​

• This report covers the period from January 1, 2026 to June 30, 2026.
• All data is sourced from provider status pages (APIs, webhooks, RSS feeds) as monitored by IncidentHub.
• Maintenance updates are excluded from this report.
• All aggregate figures in this report - total incidents, total downtime hours, category counts, month-by-month trends - are computed over a fixed set: the set of providers with complete, continuous monitoring coverage from January 1 to June 30, 2026. This includes 1,082 providers, a subset of IncidentHub's 1,125+ monitored providers. This means that providers added to IncidentHub mid-period (providers are added to IncidentHub's monitored set periodically and on request) are outside the scope.

Limitations​

• IncidentHub monitors public status pages which usually reflect outages affecting many customers. Smaller outages affecting fewer customers may not be tracked by status pages.
• Duration data reflects provider-reported timelines.
• Some large providers are not yet in the monitored set (e.g., certain APAC clouds and a number of payment, edtech, observability tools). We hope to cover these gaps in upcoming reports.
• There are providers that can potentially fall into multiple categories (e.g. AWS has cloud hosting, CDN, DNS, and so on). In such cases we included them in the category that is the most relevant. So AWS comes under Cloud Providers, not CDN/DNS and Edge Infrastructure.
• Outage counts should not be taken as a reliability ranking across providers. Providers vary in what they publish on their status pages, and a lot also depends on the provider's product offerings. E.g., Cloudflare has hundreds of edge locations around the world, and a localized outage in one POP still counts as one outage.

This report does not rank providers.

H1 2026: Outage Numbers at a Glance​

H1 2026 Outage Statistics​

• Total outages tracked across all providers: 30,246
• % of monitored providers that experienced zero outages in H1 2026: 15.9%
• Worst single month by outage count: May 2026 with 6,070 outages
• Most outage-prone category: Cloud Providers with 4,723 outages across 86 distinct providers
• Highest average outages per provider per month: 9.44 in May 2026 (across 643 providers that had at least one outage that month)
• Top 2 categories which had upstream issues (i.e. another provider) as the root cause: Cloud Providers and Developer Tools

H1 2026 Outages by Category​

Cloud providers topped the list with 4,723 outages across 86 providers, with Developer Tools coming in a close second with 4,589.

This report covers some key categories in detail.

Cloud Provider Outages​

Cloud Providers saw the highest number of outages in H1 2026 - 4,723 across 86 separate providers. These include both major and minor incidents. May 2026 saw the highest number of cloud provider outages at 1,139 (in 67 different providers). The upward trend from January to May slowed down in June.

In early March, AWS reported that their Middle-Eastern datacenters (me-central-1 and me-south-1) "experienced physical impacts to infrastructure as a result of drone strikes" in the armed conflict in the Middle East. The downstream impact was significant, with services like Salesforce and Slack which have data residency requirements experiencing disruption. Salesforce undertook a migration of user data to their Sweden region, which took around 3 weeks and 5 days to complete. Confluent advised customers with workloads in these regions to migrate to other regions.

Since then, AWS has stated that me-central-1 is currently unable to reliably support customer applications, though some workloads continue to function normally, and recommends customers migrate accessible resources and restore the rest from remote backups. The me-south-1 region is described as currently unavailable, with customers advised to recover resources in other regions. Billing operations are suspended in both, and AWS expects restoring normal operations to "take several months."

Other incidents lasting for a significant duration were:

• Google Cloud's network traffic originating from Delhi, Chennai, Mumbai and surrounding areas experienced degradation due to a datacenter fire. It took 21 days 12 hours to fully mitigate.
• OVHcloud's Web Hosting Incident. 5 days 18 hours to fully mitigate.
• Hetzner's Object Storage degradation in nbg1. 27 days 16 hours to fully mitigate.
• Hetzner's Object Storage degradation in hel1. 31 days 13 hours to fully mitigate.

DoIT's incident which caused inflated billing data for their Cloud Intelligence product took around 9 days to fully fix.

Another prolonged outage was in Scaleway's object storage service - which took around 51 days as they had to roll out a fix to every region. There was no impact on user data, as noted in the incident update.

In terms of impact and not just duration, Railway's outage on May 19, 2026 was caused by GCP's automated account suspension and led to widespread downtime for Railway's customers. Also in May, Canvas (Instructure) had a security incident which affected their service, disrupting educational institutions across the world.

Amazon Web Services (AWS)​

• Total H1 2026 incidents across all tracked regions: 14, including the 2 Middle-East region outages.
• Keeping aside the two Middle-East regions as a special case, the most downtime was seen in us-east-1, followed by eu-west-1.

February saw 4 AWS outages, but the average has stayed around 2 per month.

AWS services affected most frequently were Amazon Elastic Load Balancing, Amazon EKS, AWS NAT Gateway, and OpenSearch.

The longest outages (again, excluding the Middle-East region outages) were:

• Fable 5 and Mythos 5 Access - affecting AWS Bedrock (June 13-15, 2026). AWS closed the outage on June 15 while the suspension continued till July 1.
• Increased Error Rate and Latency in EC2 affecting us-east-1 services (May 8, 2026).
• CloudFront change propagation issues (February 10-11, 2026) affecting global services like Route 53.

Microsoft Azure​

• Total H1 2026 incidents across all tracked regions (public status page data only): 14
• Most outages in February 2026 with 5 incidents

Both East US and West US saw 3 outages each.

Most impactful Azure outages in H1 2026 were:

• Control plane issues in East US on April 24, lasting 12+ hours. The impact was felt across multiple Azure services in multiple AZs in the region. The outage started as lock contention errors in the PubSub control plane in a single AZ. The errors in turn triggered a failover which remained incomplete. A manual failover attempt was also unsuccessful, and was followed by issues in other AZs.
• Outage affecting Azure Virtual Machines, Azure Kubernetes Service, and Azure DevOps between 18:03 UTC on February 2, 2026 and approximately 00:30 UTC on February 3, 2026.

Google Cloud Platform (GCP)​

• Total H1 2026 incidents across all tracked regions: 2

Note that this does not include outages in other Google services like Google Maps Platform, Google Play, or Google Ads. Note also outage counts are not comparable across the providers in this section. Each provider decides what goes on its status page and at what granularity. A lower count does not mean a provider is more reliable - it may be publishing only widespread incidents, or grouping into one entry what another provider would post as several.

Oracle Cloud Infrastructure (OCI)​

• Total H1 2026 incidents: 2

Oracle Cloud had one major networking-related outage in US East on March 3-4, 2026. The root cause was identified at around 00:44 UTC on March 4, 2026, after around 10 hours since the outage started. Fixes were applied and the outage was declared resolved after 8 more hours.

Edge, CDN and DNS Outages​

Edge, CDN, and DNS providers sit upstream of most of the services covered in this report. They form the core infrastructure components of the internet. As we have seen in both 2025 and 2026, they can have a ripple effect across thousands of downstream websites, SaaS applications, and other services.

When one of them fails, the outage multiplies across every site and SaaS product that depends on that provider for traffic, caching, or name resolution. A well-engineered application can still go dark if its CDN returns errors or its DNS stops resolving. We saw this in Cloudflare's November and December 2025 outages, and the same pattern shows up in H1 2026.

16 providers in this category had a total of 1,018 outages in H1 2026, with April seeing an uptick.

Cloudflare​

Cloudflare had 487 major and minor outages in H1 2026. April saw the highest number of outages at 98. The graph for Cloudflare roughly mimics the overall Edge, CDN, and DNS graph above because of Cloudflare's widespread presence.

In 2025, Cloudflare saw two major outages - one in November and one in December. The November 18 outage affected thousands of sites and services, multiplying the impact downstream.

Some of the major Cloudflare incidents in H1 2026:

• An increase in HTTP request latency in Newark, NJ started on February 16, 2026 at 10:19 UTC, when Cloudflare began investigating higher than usual latency for a subset of HTTP requests. A fix was implemented on February 26, 2026 at 10:12 UTC - roughly 10 days after the incident began. Cloudflare then monitored the results for several days before declaring the incident resolved on March 2, 2026 at 09:15 UTC - about 4 days after the fix went in.
• On May 5, 2026 at 08:04 UTC, Cloudflare opened an investigation into Bot Management Issues - unexpected increases in rule matches for a couple of detection IDs. The fix landed on May 6 at 09:39 UTC, about 1 day later. Cloudflare disabled the affected feature globally while detections stabilized over the following days, and marked the incident resolved on May 18 at 21:59 UTC - roughly 12 days after the fix.
• Cloudflare Access processing delayed audit logs was first reported on April 29, 2026 at 19:19 UTC. Cloudflare had a fix in place by 19:56 UTC the same day - under 40 minutes after the investigation started. Access itself stayed fully operational; the remaining work was clearing a backlog of audit logs from April 28-29. The incident closed on May 8 at 19:53 UTC, about 9 days after the fix, once ingestion of the delayed logs was complete.

Fastly​

Fastly had 161 outages in H1 2026, with outages peaking in January and April.

• Elevated 425 responses in Google Chrome 145 release was posted on February 13, 2026 at 15:23 UTC after Fastly received reports of increased 425 Too Early responses for users on Google Chrome v145. The cause was a change in Chrome's retry logic for requests with query parameters, and not a Fastly platform defect. Fastly temporarily disabled 0-RTT on shared configurations on February 25 at 19:30 UTC as a mitigation - about 12 days after the incident opened. The Chrome team merged a fix in version 145.0.7632.115 on March 3, and Fastly marked the incident resolved on March 10 at 15:45 UTC after confirming full mitigation.
• Fastly engineers began investigating errors for Atlanta and Miami edge users on January 25, 2026 at 01:05 UTC. Elevated errors and intermittent latency hit customers routed through those two POPs; all other Fastly products and services were unaffected. A contributing factor was identified at 02:34 UTC, and impact was mitigated by 03:34 UTC - about 2 and a half hours after the investigation started. The incident was closed at 03:38 UTC once both POPs were fully restored.

Akamai​

Akamai had 59 outages in H1 2026, with outages peaking in April.

• An issue in the Certificate Provisioning System (CPS) in the Akamai Control Center Portal was identified on February 11, 2026 at 21:09 UTC, when users had trouble accessing CPS through the Control Center. Akamai implemented a fix at 22:10 UTC the same day - about an hour after the issue was identified - and moved into monitoring shortly after. A short recurrence on February 17 (about 25 minutes of impact) led to extended monitoring and a longer-term software change. That change completed on March 19 at 17:00 UTC, and Akamai declared the incident resolved on March 20 at 19:17 UTC.

As with cloud providers, these counts are not comparable across providers. Cloudflare, Fastly, and Akamai differ in the size of their edge networks and in how granularly they post to their status pages. A localized issue at a single POP shows up as an outage on one provider's page and may not appear at all on another's.

DNS Outages​

DNS being the address book layer of the internet, outages in DNS providers can have immediate and widespread impact.

IncidentHub saw 73 DNS-related outages in H1 2026 across 30 different providers spanning categories, including pure DNS providers as well as cloud providers with DNS services.

Identity and Access Management (IAM) Outages​

Moving up the stack, IAM is another foundational layer for applications - and where a failure can lead to users unable to use the service even if it is running.

The Authentication Dependency​

• Every application requiring a login depends on its authentication provider.
• Auth providers can provide both authentication and authorization services.
• An auth provider outage affects every downstream application using it for SSO or identity.

These factors make the authentication layer one of the highest-leverage points of failure in the modern SaaS stack.

IAM provider outages rose steadily throughout H1 2026, peaking in May, and then showed a downward trend. IncidentHub detected 244 outages across 16 different providers.

Okta recorded 13 and Auth0 19 outages in H1.

A dependency analysis of IAM outages across providers revealed downstream impact across many categories:

• Developer Tools: Draftbit was affected due to a Clerk outage.
• Cloud Providers: Cloudflare dashboard logins were affected by an Okta issue.
• IT Operations and MSP Tools: Nintex Workflow logins were affected by an identity provider outage.
• Developer Tools: Harness Traceable logins were affected by an Auth0 outage.

Other auth-related issues that caused outages:

• Communication and Collaboration: Box Drive SSO logins failed for about 3 hours on May 21-22, 2026 after an identity provider admin region was switched to passive by mistake.
• EdTech: Articulate 360 SSO provisioning was delayed for about 7 and a half hours on May 5-6, 2026 after a large internal data import overloaded user update processing.

Developer Tools Outages​

Developer tools sat just behind cloud providers for total outages in H1 2026 - 4,589 across 187 providers. An outage in this category has varying impact depending on the tool:

• Source control software issues can obstruct production hot fixes by affecting build and deploy pipelines (think GitHub Actions).
• Artifact registries can impact downstream services (think Docker Hub outages affecting Railway deployments).
• Project management tools can slow coordination rather than block production.

Developer tool outages peaked in March, with 844 incidents across 135 providers.

Source Control and Code Repositories​

GitHub Outages​

As noted in our previous report on GitHub's reliability between May 2025 and April 2026, February remained the worst month for GitHub outages. That statement remains true for this report as well.

• Total H1 2026 incidents: 169
• GitHub Actions remained the worst affected with 37 recorded incidents, with Copilot and Pull Requests being next. These components directly affect the development workflow.

One of the longest outages went on for 2 days 13 hours between April 28 and May 1, resulting in pull requests not showing up in search results. A repair job for a single repository ran without safety flags and deleted about 1.8 billion PR documents from Elasticsearch - roughly half the indexed set - while opening, updating, and merging PRs stayed unaffected.

Other Source Control and Code Repositories​

Compared to GitHub, other source control and code repositories had a much lower number of outages in H1 2026. However, it is important to note that these numbers do not take into account the number of projects hosted at GitLab or Bitbucket, and their traffic. GitHub has seen an explosion of traffic since 2024 which has stressed its infrastructure.

GitLab:

Bitbucket:

Package and Artifact Registries​

Artifact registries are almost invisible layers in the modern stack. They can impact both deployment pipelines (e.g. hot fixes rolling out to production) and application runtimes (e.g. autoscaling failures due to image pull errors).

March and April saw npm outages increase, and it improved after that.

Docker Hub outages also showed a decrease by the time we reached June.

Communication and Collaboration Outages​

Messaging, video, and document platforms are part of the daily workflow of almost every person in an organization - not just engineering. When Slack, Teams, or Zoom fails, the outage is immediately visible across the organization. These tools are also how incident response itself is coordinated in some teams, so an outage during a broader infrastructure event compounds the damage.

This category saw 1,920 outages across 75 distinct providers in the first half of 2026.

Messaging Platforms​

Slack experienced 57 incidents in H1 2026, whereas Zoom had 131 in the same period.

Zoom outages peaked in January.

Document and Knowledge Platforms​

Project Management Tools​

Linear, Asana, and Monday.com are compared here as work-tracking tools. Outages in this group slow down coordination rather than block deploys, which is why they rarely appear in incident retrospectives despite the volume.

AI and LLM Tools Outages​

AI and LLM tools have a wider impact due to their widespread integration in the ecosystem, especially developer tools.

AI Providers as a Key Infrastructure Dependency​

LLM APIs have become increasingly integrated into the core workflows of developer tools, customer support platforms, communication, and productivity tools. Any upstream outage either results in a partial or a complete loss of functionality. Developer tooling often uses multiple AI providers for different use cases as well as for fallback, but that is not always an option for other categories. This leaves the other categories with not much choice when the upstream LLM has a problem.

AI and LLM tools saw 2,730 outages across 34 distinct providers, with outages peaking in January.

Significant AI and LLM Incidents​

• E2B: Intermittent volume request timeouts: volume requests began timing out on June 2 at 22:56 UTC and stayed degraded until June 23 at 06:13 UTC - 20 days 7 hours.
• Google AI Studio: AI Studio Build experiencing latency issues (no permalink available): Build latency ran from April 2 at 13:00 UTC to April 17 at 00:00 UTC - 14 days 11 hours.
• DataRobot: Problem connecting to DataRobot due to client browser caching: connection failures tied to browser caching stretched from January 8 at 18:15 UTC to January 22 at 14:19 UTC - 13 days 20 hours.
• OpenAI: FedRAMP workspaces and API orgs have degraded performance: FedRAMP workspace and API org performance degraded from June 15 at 22:12 UTC until June 26 at 23:07 UTC - just over 11 days.
• Deepgram: Voice Agent third-party provider instability (Google Gemini LLMs): Voice Agent instability from an upstream Gemini LLM issue lasted from April 21 at 15:59 UTC to May 1 at 18:21 UTC - 10 days 2 hours. This is an example of an enterprise AI solution provider being affected by an upstream LLM provider issue.
• Google AI Studio: Gemini API is having some issues serving recently created keys (no permalink available): Newly created Gemini API keys had problems from April 17 at 23:00 UTC to April 28 at 01:00 UTC - 10 days 2 hours. The workaround was to create a new key.

Anthropic Fable 5 and Mythos 5 Suspension​

Although this was not an outage in the true sense, it deserves mention. Anthropic suspended access to Claude Mythos 5 and Claude Fable 5 from June 13 at 00:50 UTC until July 1 at 19:26 UTC - 18 days 19 hours - in compliance with an export control directive. Resolution fell just outside the H1 window.

The suspension of Fable 5 and Mythos 5 by Anthropic resulted in the following downstream providers being affected:

• Amazon Web Services: Fable 5 and Mythos 5 Access: Bedrock access to both models was disrupted.
• Notion: In compliance with Anthropic and US policy, we have disabled Fable 5 in our product: Fable 5 was disabled in Notion in line with Anthropic and US policy.
• GitLab: Claude Fable is not available through GitLab.com: Fable was unavailable on GitLab.com.
• Netlify: AI Gateway: Claude Fable 5 unavailable: the AI Gateway could not serve Claude Fable 5.

Payment Infrastructure Outages​

Payment infrastructure is a critical layer for any SaaS company. Payment outages have an immediate impact, but failed attempts are often retried successfully.

Payments saw 2,204 outages across 33 distinct providers, with outages peaking in June. Outages show an upward trend since January.

Stripe outages peaked in March and May with 11 each.

The US Federal Reserve's FedACH Services experienced an internal systems processing outage beginning on March 3, temporarily taking the FedACH application offline and delaying file distribution and settlement for multiple ACH processing windows. This affected US payouts, top-ups, bank debits, and bank transfers flowing through Stripe and other processors, and was also surfaced by Stripe on its own status page.

PayPal showed a decrease in outages since January, in contrast to Stripe.

Observability, Monitoring and Incident Management Tools Outages​

This is the group that knows about outages of other tools, so outages in this category essentially result in either a slowdown or a complete loss of visibility into whether something is wrong. Monitoring tool outages can result from either their internal issues or issues with the cloud providers they depend on, since most monitoring and alerting tools are themselves cloud-hosted SaaS services.

Observability and Monitoring​

• 701 outages across 34 distinct providers in H1 2026.

A comparative view of selected observability and monitoring tools:

Incident Management​

• 47 outages across 4 distinct providers in H1 2026.

A comparative view of selected incident management tools:

EdTech Outages​

EdTech is becoming increasingly reliant on AI. In addition to infrastructure, upstream AI providers are also in the mix of factors that can cause outages. EdTech has specific demands like fixed academic calendars, which cannot be rescheduled, and which makes it different from enterprise SaaS. Scalability and reliability, both from the application and from dependent services like auth providers, are critical.

EdTech platforms saw 420 outages across 38 distinct providers. H1 2026 also showed that security-triggered outages - not just infrastructure failures - can take platforms offline at scale, as the Canvas incident in May demonstrated.

Canvas (Instructure) - May 2026 Security-Related Outage​

• A security incident attributed to a ransomware group caused a platform-wide outage. The outage occurred during the final exam period for many institutions globally.
• The group claimed that approximately 9,000 institutions were affected; some institutions lost access for multiple consecutive days. In an update, Instructure noted that they have "blocked the unauthorized access, remediated the vulnerabilities and privilege escalation paths used".

H1 2026 Outage Patterns​

Cascading Outages​

In addition to specific services that caused downstream outages, we analyzed the dataset as a whole.

This chart shows how many outages in each category were caused by something that they depended on.

Cloud providers themselves were among the most affected by upstream outages.

This analysis has some caveats:

• This does not reveal second and higher order dependencies.
• This is based on confirmed mentions of upstream outage(s) as the root cause in the provider's own incident report. The actual numbers are likely higher.

Month-by-Month Trend (January - June 2026)​

Duration Distribution by Month​

A quick look at the duration distribution by month (across all providers in the dataset) shows these patterns:

• Shorter (< 1 hour) outages are becoming more common.
• The number of longer outages up to 24 hours has more or less stayed the same.

The duration reflects actual resolution times. An incident that started in H1 and resolved in July is counted in its correct duration bucket, including the longest ones. Incidents still unresolved at the time of writing are marked Unresolved and excluded from the duration distribution chart, though they remain in all outage counts.

Comparative View of Categories by Month​

A comparative view of the top 12 categories by outage counts per month:

Patterns in Distributed Infrastructure Outages​

Global Propagation of Localized Trigger Points​

The trigger points for outages in globally distributed infrastructure providers are usually localized but they quickly cascade. This is often an outcome of the system's design. Such systems are built to propagate changes quickly, usually in the control plane, across the provider's global infrastructure. A misconfiguration propagates at the same speed as a good one. Examples are:

• Microsoft Azure's February 2026 Outage that affected Azure Virtual Machines, Azure Kubernetes Service, and Azure DevOps was triggered when a remediation policy incorrectly disabled anonymous access on VM extension package storage. This state propagated across public cloud regions, causing control plane failures for provisioning and scaling.
• GCP's June 12, 2025 outage that was caused by a bad automated update to Google Cloud's quota check system. The update propagated across the entire global network, affecting external API requests and impacting many products. Google noted in their incident report that "data replication needs to be propagated incrementally with sufficient time to validate and detect issues".
• Microsoft Azure's October 29, 2025 outage was triggered by incompatible metadata in Azure's CDN. The bad configuration had already propagated to edge servers by the time their internal config protection system detected and stopped new and inflight requests.
• Cloudflare's November 18, 2025 outage - one of the most impactful last year - was caused by a larger than expected file input into their Bot Management system. This change propagated quickly across the world. Cloudflare put into action their "Code Orange: Fail Small" plan to do a controlled rollout for any configuration change that will propagate across the network to prevent such issues.

Automated Policy Enforcement as a Risk​

GCP's automated suspension of Railway's production account is the most recent example of this. As automated enforcement becomes more common in cloud platforms, organizations will need to treat this as a risk to prepare for. Solving this at the architecture level is the best way to prepare for it.

Control Plane Resilience Matters More​

The data plane can stay healthy while the control plane fails. Even if your VMs, databases, etc are resilient to a single zone or even a single region failure, but your control plane is not, a failure in the latter can render your application unusable. A multi-cloud approach is often touted as a way to achieve resilience. Notwithstanding the technical complexities of a multi-cloud approach, combined with the fact that your dependencies may not be multi-cloud, a resilient control plane should be a key part of your approach.

Recovery Can Trigger Secondary Outages​

Depending on the nature of the outage, recovery can trigger subsequent, smaller issues. Queued jobs, thundering herd issues, and rate-limiting by third-party services (triggered by requests from the recovering service) can all slow down the overall recovery process.

Conclusion​

H1 2026 was defined by dependency risk. Across 30,246 outages and 1,082 providers, cloud providers and developer tools had the highest volume of outages. Many incidents with wide reach originated one layer upstream, in edge and CDN networks, identity providers, LLM APIs, or a cloud control plane. May was the heaviest month.

The first half of 2026 also produced failure modes that outage duration and count do not capture. Outages resulting from automated policy actions (Railway), security incidents (Canvas), AI model access suspension (Fable 5 and Mythos 5) were the significant ones.

Four patterns held across the data. Localized triggers propagate globally when control planes are built for fast replication. Outage recovery generates its own load and can extend an incident well past the original fault. Shorter outages are becoming more common. Automated policy enforcement is a risk to consider.

This report is a record of what providers published on their public status pages between January 1 and June 30, 2026. It is not a measure of customer impact, and the outage counts are not a reliability ranking: providers differ widely in what they choose to publish, and this report does not normalize for severity. The counts are for status page activity.

The practical takeaway is to know your first- and second-order dependencies, and watch them in one place. A vendor outage monitor like IncidentHub surfaces upstream outages across cloud, SaaS, AI, and edge providers before your users report them.

FAQ​

All images are generated from IncidentHub's aggregated data. If you wish to reuse them, please do so with attribution.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All the logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

You might also like:

• GitHub Outages 2025 - 2026: Reliability Analysis and Outage History
• The Definitive AWS Outage Report 2025: Reliability Analytics and Cascade Impact
• Major Cloud Outages of 2025

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.

• Introduction
• Methodology and Coverage
• Timeline of the Outage
• What is a VPC Origin and What Went Wrong?
• Cascade Impact on Other Services
• The EdTech Pattern
• Surviving CloudFront Outages
• Conclusion
• FAQ

Methodology and Coverage​

IncidentHub monitors uptime of all AWS services and regions, and detects outages by monitoring the public status page periodically. In addition, IncidentHub also detects outages in downstream services that depend on AWS services.

Not all services acknowledged the CloudFront outage on their status pages, so the actual number is likely to be higher than what we detected. A CDN, cloud provider, or a key service like authentication usually has a big blast radius.

Timeline of the Outage​

Impact window: 07:45–11:18 UTC (3 h 33 m).

Note: the 11:18 recovery time comes from the retrospective 12:21 summary, while the live 11:27 and 11:57 updates still described recovery as in progress.

Source: AWS's own outage summary

What is a VPC Origin and What Went Wrong?​

CloudFront serves content from its edge locations to end users. It fetches content from the customer's services - "origins" in CDN parlance - which can be public or private. Introduced in late 2024, VPC Origins allow CloudFront to pull content from private subnets in the customer's VPC. This expanded the source of content from previous sources such as Amazon S3 to include ALBs, NLBs, and EC2 instances in private subnets.

An "internal constraint" on the fleet that manages connections to private VPC origins led to it not being able to load updated network configurations correctly. As of this writing, AWS has not provided any details of what the constraint was.

However, it is interesting to note that the failure mode is related to the global control plane, similar to what was observed in last year's cloud provider outages:

• Google Cloud Platform - 12 June 2025 - Bad configuration update propagated globally.
• Microsoft Azure - 29 October 2025 - Incompatible metadata changes propagated globally.
• Cloudflare - November 18 2025 - A bad configuration change was propagated globally to its bot management system.

In each case in 2025, a bad configuration change was propagated globally, affecting a large number of customers. In July 16's outage, it was a failure to load distributed configuration. Although we are yet to receive more details on the root cause, based on AWS's preliminary report, it looks like the "constraint" affected the connection management fleet in a widespread manner.

Cascade Impact on Other Services​

CloudFront being a global CDN, its downtime affected a large number of other SaaS and Cloud providers, and they in turn affected others as well as their customers.

IncidentHub detected cascading outages in many downstream services. Some notable ones were:

The EdTech Pattern​

Canvas and Blackboard were affected again - echoing the October 2025 outage, where Canvas and Blackboard were down for 17+ hours, affecting thousands of students and teachers.

Surviving CloudFront Outages​

Although it is not easy to completely avoid the impact if you are using any kind of SaaS in your stack, there are some considerations to keep in mind:

• Know which dependencies your stack has. This is easier said than done, because your first level dependencies can have second and higher level dependencies, and so on.
• Monitor the provider status page for recommended workarounds like AWS's team suggested in their update for the July 16th outage.
• Pre-plan the origin-type fallback - the workaround only helps if you've rehearsed it. If you use Terraform or a similar IAC tool, make the changes and keep it tested and ready to deploy when the time comes.
• Map second-order dependencies, especially identity providers and CDNs. Identity providers failing can lock your users out of your application even if your app is running fine otherwise.
• A global control/config plane doesn't respect region boundaries, so region failover wouldn't help in such cases. Multi-cloud brings its own overhead, and your other SaaS dependencies may not be multi-region/multi-cloud.
• Monitor the first level dependencies for any outages using a status page aggregation service like IncidentHub.

Conclusion​

The July 16th outage was short - about three and a half hours - and narrow in cause, but its reach was global. A single feature, VPC Origins, failing to load its configuration correctly was enough to take down websites and applications well beyond AWS itself, because CloudFront sits in front of so much of the internet. The downstream impact followed a familiar pattern. Identity providers, AI and developer tooling, and education platforms were all affected, and some of them took their own customers down in turn. An identity provider being unreachable can lock users out of an application that is otherwise running fine. Outages like this are difficult to avoid entirely, because most stacks ultimately rest on a handful of providers, and those providers' global control planes don't respect the region or cloud boundaries you might be counting on for failover. What you can do is know your dependencies - including the second- and third-order ones - and monitor them, so that you find out an upstream provider is down before your users tell you.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by AWS or any of the services and vendors mentioned in this article.

This article was first published on the IncidentHub blog.

You might also like:

• The July 23 2026 Azure West US Outage: IP Route Removal and Downstream Impact
• The July 24 2026 AWS us-west-2 Outage: Network Routing and a Long Recovery Tail

Introduction​

Handling client calls when a third-party vendor has an outage - this will sound familiar if you are a managed service provider (MSP). Your first instinct would be to check if the vendor's status page or social media handle shows anything, or check crowdsourced websites like Downdetector. Or even ask your client to check themselves.

These approaches do not scale when you have more than a few clients, many vendor status pages to check, and clients with different stacks. Public status pages do not always show your client specific issues (e.g. Microsoft 365, Microsoft Azure). Crowdsourced websites can have false positives, and you are delegating something that you should have handled yourself to a third-party website.

This article is about two different strategies you can use to close the gap. Both give your clients an automatically updated status view of the third-party SaaS and Cloud services they depend on, with data gathered from official sources, under your brand. One is a hosted, white-labeled status page you switch on and never have to build. The other is a dashboard you build yourself on top of a live data feed. Which one fits your situation depends on whether you have developers and what you've already got running.

• Introduction
• What Clients Actually Need To See During a Vendor Outage
• One MSP. Many Clients. Many Stacks.
• Two Ways To Give Each Client a Scoped View
  • Option One: The Hosted, Filtered Status Page
  • Option Two: The Custom Dashboard You Build on the Data Feed
  • Which One Fits You?
• Decision Table
• Where Else Can the Signal Go?
• What This Doesn't Solve
• Where To Start
• Conclusion

What Clients Actually Need To See During a Vendor Outage​

When a client reports that something is broken, they're asking two questions - Is it the vendor or is it us - meaning you, the MSP. And if it's the vendor, are you already on it? A good answer can settle both questions quickly and comes from somewhere they trust, which is again you.

Crowdsourced websites are the default go-to sites for a lot of teams, and they have their uses: they are an easily accessible source for information on whether a problem is widespread or localized to a few users. However, they collect user reports only, and are not linked to official vendor sources. A spike in reports in such websites is a signal that something might be wrong. The problem may not even be with the service but with the users' ISP - in which case you are seeing a false positive. It doesn't tell you that Xero has acknowledged an outage or that Microsoft has opened an advisory for Exchange Online. The official status pages have this information, but there we have a caveat.

Services like Microsoft Azure and Microsoft 365 do not update their public status pages for outages affecting specific tenants only. The latter data are available only on the Service Health Dashboard in your Microsoft account. Your clients most likely won't have access to it.

Also, crowdsourced outage report websites are a consumer brand. As an MSP, when you send a client there, you've handed them a possible answer through a third party and put someone else's logo in front of your client instead of yours.

The initial gap thus is about ensuring the client gets accurate information directly from the vendor. That information can come from the vendor's status page, or from their internal health APIs, and it should also be scoped to only the services that the client actually uses. The points below are about meeting this goal without opening 30-40 browser tabs with status pages.

One MSP. Many Clients. Many Stacks.​

No two clients have the same stack although there can be overlap between services. One client can run Xero for accounting, Microsoft Teams for team communication, Azure for cloud workloads, whereas another can use MYOB, Slack, and Google Cloud.

So even if you had a hypothetical single dashboard that shows status from every single service you manage, it would be difficult for your clients to navigate and get anything useful out of it when it comes to answering the question "Is so-and-so down?" The problem is compounded by services that have internal health dashboards like Microsoft 365, as their status is tied to specific tenants.

The not-so-great options here are to keep a spreadsheet somewhere mapping each service to its status page, and which clients use what. It's not hard to imagine how unmanageable it will be.

A shared, single status page also has the same failed outcome - it's noise. Nobody wants to see service statuses they don't use. Per-client isolation is a basic requirement for a status page. The section that follows will walk you through examples of two possible solutions.

Two Ways To Give Each Client a Scoped View​

There are two ways to deliver a per-client view, and the right one depends on your team and their expertise more than your size. IncidentHub provides both, working from the same set of official vendor status feeds - around 1070 vendors as of this writing - so that the underlying data is identical (and official) whichever option you choose. The difference between the approaches is in who builds the front end.

Option One: The Hosted, Filtered Status Page​

The first option is a status page you don't build yourself. You pick the services a given client depends on, and you get a page that shows only those - white-label, on your own domain, isolated so that client sees nothing belonging to anyone else. You send them the link, or embed it where they already look. When Xero opens an incident, it shows up on that client's page.

What the client sees is a clean page with your branding and your domain in the address bar. There's no mention of any monitoring vendor, including the one providing the data. To the client it reads as something you built and run. The status reporting of the vendors' services you manage is part of your service.

Alternatively, you can also host each client's status page on a subdomain of the client's domain - e.g. vendor-status.clientdomain.com and use their branding.

This is the path for the majority of MSPs because it costs no engineering time. There's nothing to host, no status pages to parse, and no custom application to maintain. Monitoring your service stack starts and ends with these steps:

1. Choose the vendors you want to monitor along with their regions/components.
2. For private status (like Microsoft 365 and Microsoft Azure), connect to the tenant's health using official Microsoft APIs in a few clicks.
3. White-label your status page.

If your reason for not doing per-client status pages so far has been that it's one more thing to build and run, this removes that reason. The tradeoff is that you take the page roughly as it comes: you control which services appear and the branding, not the layout or the workflow around it.

Option Two: The Custom Dashboard You Build on the Data Feed​

The second option is for MSPs who already run a client portal, an internal NOC view, or an app they'd want to surface this inside. Instead of a hosted page, you take the same vendor-status data as a live feed and render it yourself.

Technically it works off a webhook. IncidentHub pushes a structured JSON payload to your secure webhook endpoint every time a monitored service changes state - an incident opened, updated, or resolved. The webhook docs cover the payload shape and how to register your endpoint.

From that point onwards in the flow, it's in your control. A worked example:

1. Your webhook endpoint receives the request payload
2. Updates a per-client status panel in your portal or posts a message to the right Microsoft Teams channel
3. Optionally, opens a ticket in your ticketing system

The data driving all of this is the same official vendor status (including internal health status for services like Microsoft 365 and Microsoft Azure after connecting to their tenant's health using official Microsoft APIs) that powers the hosted page; the presentation, the placement and the workflow are entirely under your control.

One MSP we work with does exactly this. They ingest the feed into their own client-facing app, so their customers see vendor status inside the same portal they already use for everything else, with no third-party branding anywhere in sight. The upside of building it yourself is that you can customize the presentation and workflow to your needs. There is a cost - this path assumes you have a developer and want to maintain a small integration. If you don't, the hosted page gets you to the same place for the client without writing a single line of code.

Which One Fits You?​

The deciding factor here is primarily whether you have development capacity and something to build into. If you already run a client portal or an internal dashboard and have someone who can wire up a webhook, building it yourself puts vendor status where your clients and techs already are. If you don't, the hosted filtered page gets a client a correct, branded, scoped view today, with a mostly self-service setup.

Plenty of MSPs will do both, and that is reasonable too - hosted pages for most clients, and a custom build for the one or two larger accounts that already have a portal worth surfacing it in. The data's the same underneath, so mixing the two costs you nothing in consistency.

In either case, you have replaced two bad defaults. You're no longer tabbing through vendor pages per client during an incident, or logging into admin health dashboards, and you're no longer sending clients to a consumer site to find out whether their cloud provider is down. The client gets all the information they need, scoped to their stack, in one place.

Decision Table​

Where Else Can the Signal Go?​

Once vendor status is available as a clean, normalized feed, the hosted page and the custom dashboard are two possible destinations for it. A few others are worth knowing about, with one caveat.

A filtered view can be embedded into a staff or client portal, or into a ticketing tool, so status sits next to your workflow rather than in a separate tab. The feed can be pushed into a client-portal platform like CloudRadial - as a data source, putting vendor status in front of clients where they already log in. It can be fed into your operational tooling for correlation as well - a vendor incident lined up side by side your own alerts in Datadog, PagerDuty or Grafana shortens the time it takes to conclude "this is them, not us" when the provenance of an incident is still unclear.

What IncidentHub does today is the webhook and the hosted, filtered status page. The rest - feeding the data into a client-portal platform or an observability tool - is a direction the webhook supports, something you'd wire up yourself. It's not a button that ships today. It's also worth pointing out that the same monitoring is also applicable for the tools you run yourself - your PSA and RMM, ConnectWise or NinjaOne - so you can also find out at a glance when your own stack is down, not just a client's vendor.

What This Doesn't Solve​

There are a couple of limits here. First, the official vendor status is only as good as the vendor: some post quickly and accurately, whereas others lag a real outage by minutes or quietly update the page after it's over. Sometimes the lag is due to the vendor's own on-call or other internal processes. However, when the status is updated, it is official.

Second, this watches your clients' external dependencies, not their own infrastructure. It tells you when Xero, Microsoft 365 or a client's ISP is down - it doesn't tell you when the client's own server, network or line-of-business app has problems. That's a separate job their existing monitoring needs to cover. The vendor monitoring sits alongside it to handle the vendors, which most monitoring can't see.

Where To Start​

If you've been meaning to give clients a real answer when a vendor breaks, start with the constraint that actually decides it: do you have a developer and somewhere to build into. If yes, take the feed and put vendor status inside the portal or dashboard your clients and techs already use. If no, switch on a hosted filtered page per client with a few clicks.

The point of either is the same. When a client asks whether a vendor is down, the answer comes from you, scoped to what they run, and quickly. They never have to see a vendor's status page to get it. If you want to see the per-client page and the feed in practice, the demo and the MSP pages walk through both.

Conclusion​

Vendor outages are one of the few IT problems that genuinely aren't your fault. However, the minutes after one occurs are still yours, and how you handle them matters for your client relationship. Monitoring vendor outages in a reliable, useful way is non-negotiable. The gap between tabbing through status pages while they wait and handing them a branded page that already shows what's wrong is small to set up and very visible to the client. Whichever route you pick, the shift in trust and the value you provide are the same. Vendor status stops being something you scramble to look up and becomes something the client can already see, scoped to their services, in one place.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All the logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

You might also like:

• Six IsDown Alternatives in 2026
• How to Monitor SaaS Status in 2026 : A Complete Guide
• Top 6 Reasons Why You Need a Status Page Aggregator

IncidentHub's latest product update includes private status ingestion for Microsoft Azure and Microsoft 365, a simpler UI for alerts configuration, an option to disable the public status page, and a better looking status page layout. Plus, support for more vendors (1070+ and counting).

As always, I am grateful to all our customers and beta testers who have shared their feedback which has made IncidentHub better.

• What's New in IncidentHub in June 2026?
• Private Status Ingestion for Microsoft Azure and Microsoft 365
• Simpler Alert Configuration UI
• Disable your Public Status Page
• A Better Status Page Header
• New Vendors

Private Status Ingestion for Microsoft Azure and Microsoft 365​

The official Microsoft 365 status page shows only widespread issues or when outages prevent admins from "accessing Service health in the Microsoft 365 admin center" (quote from their status page). Your tenant specific incidents are gated behind the Microsoft 365 Service Health dashboard's login. The same goes for the Microsoft Azure status page.

IncidentHub's Microsoft 365 and Azure integrations pull that data directly from your tenant and display it alongside your other SaaS/Cloud dependencies' health using the official Microsoft Service Health APIs.

The integration uses Microsoft's standard APIs and authentication mechanisms. The connection is read-only - meaning IncidentHub has only read access to your service health data. The advantage of these integrations is that you can:

• Monitor your Microsoft 365 and Azure services in one place alongside your other SaaS/Cloud dependencies.
• Get real-time alerts for your Microsoft 365 and Azure services, and only the ones that affect your business.
• Track historical uptime data for your Microsoft 365 and Azure services.

Azure and Microsoft 365 join Infor Cloudsuite in our list of private status ingestion for enterprise customers on IncidentHub's Business plan.

The Business plan's other features include:

• Integration with 4 ticketing systems - Zendesk, Freshdesk, BoldDesk, Atlassian Jira Service Management
• Whitelabeled public status page - which lets you remove the IncidentHub branding and point your custom domain to it
• Multiple Teams support with upto 20 Teams

Simpler Alert Configuration UI​

Previously, you could turn off both outages and maintenance (where applicable) alerts for a service. This was too complex for several reasons:

1. Unchecking maintenance was sometimes interpreted as "I am not interested in maintenance for this service" - which has a broader meaning than just alerts in your channels. It was also interpreted as "I don't want to see any maintenance related stuff anywhere" - in alerts, in the status page, in the incident timeline, and so on.
2. Because of #1 (checkbox's result reflects everywhere - which actually is perfectly in line with IncidentHub's filtering philosophy), the ability to turn off both outages and maintenance did not make sense anymore. If somebody turned off both, why have the service in your list at all?

The UI is now simplified in that you can choose to turn off maintenance related information completely, not just in alerts. The option to turn off outages is no longer there. The maintenance option is turned off by default.

Unchecking this turns off:

• Maintenance alerts
• Maintenance related updates in the availability dashboard and the incident timelines
• Maintenance related badges in the status page
• Upcoming maintenance widget in the public status page
• Upcoming maintenance widget in the dashboard

This setting remains per-service.

Disable your Public Status Page​

If you are on an IncidentHub paid plan, the public status page is available by default. It is also enabled - so anybody can access it if they have the URL. You can add a password to it if your plan supports it.

You can now turn off the status page completely if you don't want anybody accessing it. A typical use case is when you are pushing alerts to an external tool like Microsoft Teams or Slack, and you prefer to stay on top of outages there as it fits into your workflow.

This setting is at the top of your status page configuration page.

A Better Status Page Header​

This is a small change in the header layout of the status page. The company name and title are bigger, and the logo + company name and page title are now side by side instead of vertically stacked. The side-by-side layout makes better use of the available space, and the larger font size makes the company name and title more prominent. This is automatically applied to all your status pages.

Check out the IncidentHub demo status page to see the new layout in action.

New Vendors​

We've added support for more vendors including Broadcom, Runframe, Mosyle, Google AI Studio, Square, MagicSchool and many more. This brings up the total number of supported vendors to 1070+.

Keep watching this space for more updates to IncidentHub.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All the logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

IncidentHub's latest product updates include a new Business plan with Teams support, early outage detection v1, and more integrations with ticketing systems. The public status now includes a disable feature. As before, many features are driven by feedback, and I am grateful to all our customers who have shared their feedback with us.

• What's New in IncidentHub in May 2026?
• Business Plan with Teams
  • A Closer Look at Teams
• Early Outage Detection
  • What Community Reports Do
  • What Community Reports Are Not
• Atlassian Jira Service Management Integration
• Public Status Page Improvements
• More Vendors and Performance Improvements
• Website

Business Plan with Teams​

IncidentHub's Business plan - meant for enterprise customers - is now generally available. It includes Teams support with upto 20 Teams, unlimited users, upto 300 services, and support for all our integrations.

The Business plan's other features include:

• Private status page ingestion
• Integration with 4 ticketing systems - Zendesk, Freshdesk, BoldDesk, Atlassian Jira Service Management
• Whitelabeled public status page - which lets you remove the IncidentHub branding and point your custom domain to it

A Closer Look at Teams​

An IncidentHub Team behaves the same way as a standalone IncidentHub account but within the same login/account boundaries. If you have a Business plan account, you can create up to 20 Teams. Each Team has its own set of

• Monitored services
• Alert configuration - component filters, lifecycle filters, outage/maintenance toggle
• Notification channels
• Availability dashboard
• Public status page and configuration

Monitored service configurations in one Team do not affect another Team even if they monitor the same services. E.g. Team A can monitor Amazon Web Services EC2 in us-east-1 and Team B can monitor Amazon Web Services EC2 in us-central-1 in the same IncidentHub account.

Typical use cases for Teams are:

• Separate Teams in your organization who monitor different groups of services, and have different notification channels - e.g. Platform Engineering, Security, Data Infrastructure, etc. In this case, do a one-to-one mapping for your organization's teams to IncidentHub Teams. Some Teams can opt for just the status page, and some for alerts, leaving it upto them to decide.
• When you wish to route different groups of service alerts to different channels. E.g. send alerts for services critical to your business to PagerDuty, and non-critical services to Slack. In this case, create one Team for each group and add the services you need in each. Set up PagerDuty in the first and Slack in the second.
• Managed Service Providers (MSPs) who monitor services for their clients and need to keep track of each client's technology stack independent of others.

Early Outage Detection​

Vendors don't always update their status pages the moment something goes wrong. Vendor delays in updating status pages reflect their internal incident response process where they are still investigating the scope of the outage. These delays vary across vendors.

Before vendors update status pages, there are other signals that can be used to detect possible outages including but not limited to community reports, synthetic monitoring, and social media mentions.

Community reports are one of the first signals we are incorporating in IncidentHub to augment the official status page data.

Crowdsourced data (like community reports) do not replace status page data but augment them. These user reports can serve as early warning signals. If you notice service degradation or unavailability in your monitored services, you can now submit a report in IncidentHub:

• Go to the IncidentHub page for the service (e.g. Cloudflare).
• Click on "Report an Incident" and fill in the details, and submit.

What Community Reports Do​

Right now user reports are submitted and collected. IncidentHub's detection layer - which will be rolled out soon - is being built on top of these signals. We released user report collection as v1 as the foundation for the detection engine. Integration into the detection engine and alerts is coming soon.

A snapshot of user reports during the recent Railway outage:

No personal data is collected including the IP address - all reports are anonymous.

What Community Reports Are Not​

It is important to understand what community reports are not. They are not a replacement for status page monitoring. Status pages for outage monitoring remain the authoritative sources of information since they are managed by vendors directly. They also have structured, parseable data that can be consumed by automation tools. They remain the contractually significant source for tracking SLAs and planned maintenance schedules.

Atlassian Jira Service Management Integration​

Adding to our basket of ticketing system integrations which included Zendesk, BoldDesk, and Freshdesk, we now support Atlassian Jira Service Management too.

Ticketing systems notifications for third-party vendor outages help your customer facing teams to stay on top of incidents and provide timely updates to your customers without giving in to noise.

As with other ticketing system integrations, IncidentHub sends only the start alert for any outage irrespective of your other notification settings (start/end/updates). You can fine-tune other IncidentHub alerts settings for each service in your IncidentHub account.

This is available as part of the Business plan.

Public Status Page Improvements​

The public status page can now be disabled completely if you are not using it, or don't want it accessed by anyone. Typical cases where you might want to do this are:

• You are pushing alerts to an external tool like Microsoft Teams or Slack, and you prefer to stay on top of outages there as it fits into your workflow.
• You use webhooks to integrate IncidentHub alerts with a custom internal system or dashboard, and the status page is not needed.

More Vendors and Performance Improvements​

We've added support for more vendors inlcuding SurveyMonkey, Microsoft 365 (Consumer), Xero, One NZ, eWay-CRM, University of Stirling, Apple (New Zealand), MYOB, Wasabi, Voyager NZ, splose, and Backblaze. This brings up the total number of supported vendors to 950+.

To support the growing number of services, we have improved the performance of the parsing engine so that it can keep up without adding more CPU load to our servers.

Website​

Last but not the least, the IncidentHub website now makes it easier to find details about our integrations and features.

Each integration has a dedicated page - Microsoft Teams, Slack, PagerDuty, and 7 more. You can find them on the Integrations menu at the top of the website.

The features list on IncidentHub's website has also been updated to reflect the new features that we have rolled out, including private status page ingestion, real-time alerts, and multiple teams.

Keep watching this space for more updates to IncidentHub.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All the logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

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.

• Executive Summary
• GitHub by the Numbers: May 2025 - April 2026
  • Key Findings
• Impact of Outages on Developers and Businesses
  • The Ghostty Decision (April 2026)
  • Zig Programming Language (November 2025)
• Where GitHub Fails Most: Service-by-Service Analysis
  • GitHub Actions Outages
    • Significant Actions Outage Timeline
    • Root cause from GitHub's post-mortems:
  • GitHub Copilot Outages
    • Notable Copilot Outage Timeline:
  • Core Git Operations Outages
  • Pull Requests Outages: The Data Corruption Incident
  • Other Service Outages
• What is Behind the Outages?
  • AI-Driven Traffic Explosion
  • The (Incomplete) Azure Migration
  • Architectural Issues
• When GitHub Fails: Patterns in the Data
  • Severity Distribution (major vs minor)
  • Root Causes of GitHub Outages
    • Capacity Issues
    • Configuration Issues
    • Infrastructure/Network Issues
    • Internal Issues
  • GitHub's Plan to Mitigate Future Outages
• How GitHub Compares: GitLab & Bitbucket Reliability
  • Methodology
  • Incident Frequency
• The Real Cost of GitHub Outages
  • Productivity Loss
  • Business Impact
  • Trust Erosion
• Conclusion: GitHub's Reliability Crisis
• FAQ

GitHub by the Numbers: May 2025 - April 2026​

Total Incidents: 257 incidents tracked, out of which 48 were major outages. February 2026 was the worst month in this period with 37 incidents, with Feb and Apr 2026 being the worst in terms of major incidents (7 each).

Total Downtime for Major Outages: 112 hr 18 min

A major outage is defined as one that leads to significant disruption to the service, affecting a large number of users or businesses.

The frequency of major outages has been increasing since December 2025.

Most Affected Service: GitHub Actions (57 outages)

GitHub Actions was the most affected service, with 57 outages between May 2025 and April 2026.

Average MTTR: 6 hr 7 min

Key Findings​

• GitHub Actions had 3x more incidents than core Git operations
• Copilot experienced 44 outages affecting AI coding workflows
• Pull Requests had 27 outages, including data corruption

Impact of Outages on Developers and Businesses​

The Ghostty Decision (April 2026)​

Mitchell Hashimoto, co-founder of Hashicorp, announced on his personal blog that his project Ghostty will be moving out of GitHub. Hashimoto wrote that GitHub "is no longer a place for serious work" and that they have been planning to move out of GitHub for a while. The announcement comes just after the Apr 27th outage (although the timing is coincidental) - which lasted around 2 hours and 13 minutes and affected the Copilot Cloud Agent.

Ghostty is a terminal emulator that is built with Zig and has over 52k stars on GitHub.

Zig Programming Language (November 2025)​

In November 2025, the maintainenrs of the Zig programming language decided to move their project away from GitHub to Codeberg (a nonprofit alternative).

Zig's maintainers cited serious bugs with Actions and issues with the overall engineering culture of GitHub as some of the drivers behind the decision.

Where GitHub Fails Most: Service-by-Service Analysis​

GitHub Actions Outages​

IncidentHub tracked 57 incidents between May 2025 and April 2026 for GitHub Actions. GitHub Actions also had the lion's share of major incidents (16) in the same period.

The worst impacted months were Jan and Feb 2026, with 8 outages each.

Significant Actions Outage Timeline​

1st October 2025 : GitHub Actions runners on MacOS encountered a 46% error rate due to capacity constraints. The outage lasted for more than 10 hours, caused by a "permission failure" which was in turn triggered by a scheduled event.

23rd October 2025 : GitHub Actions failed to cater to all requests with 1.4% of overall workflow runs and 29% of larger runner jobs failing. The underlying cause for the customer facing impact was partially identified as a database performance degradation. Time taken to restore service: 3 hours 26 minutes.

29th October 2025 : Multiple GitHub services experienced degraded performance due to a third-party provider outage. Lasting for around 9 hours, this outage affected Codespace, Actions, Enterprise Importer, and Copilot Metrics. 0.5% of workflow runs and 9.8% of larger hosted runner jobs in GitHub Actions failed during this period. The post-mortem report acknowleges that the team will reduce critical path dependencies on the third-party provider, which was identifed as Microsoft Azure in one of the status updates.

2nd February 2026 : GitHub Actions experienced degraded performance due to an issue with their compute provider - which is Azure. Time taken to restore service: 3 hours and 40 minutes. This was an outage with widespread impact affecting Copilot Coding Agent, Copilot Code Review, CodeQL, Dependabot, GitHub Enterprise Importer, and Pages also.

27th April 2026 : GitHub Actions experienced degraded performance due to an issue with their Elasticsearch cluster. The outage lasted for around 6 hours and 16 minutes. The outage affected Pull Requests, Actions, Issues, and Packages. The incident updates mention "This is due to an ongoing infrastructure issue that we have been investigating." but does not provide any more details.

Root cause from GitHub's post-mortems:​

• Capacity constraints
• Underlying provider dependencies (Microsoft Azure)
• Database overload
• Bad configuration changes rollout

GitHub Copilot Outages​

GitHub had 44 Copilot-specific outages in the period, with 9 major incidents. Copilot had 10 outages in Feb 2026 alone.

Notable Copilot Outage Timeline:​

1st October 2025 : Gemini 2.5 Pro users experienced errors when using large context requests in Copilot. This lasted for more than 45 hours.

5th November 2025 : Copilot Code Completions was partially unavailable for around 2 hours. The outage affected around 0.9% users who saw errors while using code completion.

5th November 2025 : Another Copilot Code Completions outage, this was related to the previous outage on the same date.

9th February 2026 : This issue with Copilot Policy Propagation Delays took almost a week (6+ days) before it was pronounced resolved. The root cause was identified as a code change that led to an increase in the number of background jobs, which caused a bottleneck in the shared worker queue.

Core Git Operations Outages​

19 incidents affected Git push/pull/clone in the period, with incidents peaking in Feb 2026 with 5 outages.

A seemingly simple yet one causing major disruption incident was the one that lasted for around 47 hours between Oct 22 and Oct 24 2025. Any git operations via ssh ended up either taking a long time to complete or failing altogether. The root cause was identified as resource exhaustion on backend servers. This brings up the question of whether such key infrastructure is monitored sufficiently, and why it took so long to mitigate the issue.

A pattern seen in some of the outages affecting Git operations was being unable to handle higher load than expected, or not planning for higher load. This was seen here and, here. Some issues were due to external factors like fiber cuts.

Pull Requests Outages: The Data Corruption Incident​

Pull Requests saw a total of 27 outages in the period, with the most severe bug being the Merge Queue regression on April 23, 2026. For merge groups containing more than one PR and using the squash merge strategy, changes from previously merged PRs were reverted, effectively leaving the codebase in a corrupted state. GitHub's report said that 2092 pull requests were affected. Significantly, this outage was identified by customer reports and support cases.

According to GitHub's report, this was caused by an incomplete feature flag and inadequate test coverage.

Other Service Outages​

• GitHub Issues: 28
• API Requests: 15
• Packages: 10
• Pages: 9
• Webhooks: 17
• Codespaces: 16

What is Behind the Outages?​

GitHub's downtime is the result of multiple factors, the primary ones being the following.

AI-Driven Traffic Explosion​

2024: There was a 59% surge in the number of contributions to generative AI projects, with total projects being 518 million, according to the Octoverse 2024 report.

2025: Developers made 1 billion commits (+25.1% YoY), with 230 new repositories being created every minute. The 2025 Octoverse report also notes that "Generative AI is now standard in development".

Code pushes were 82.19 million on average per month in 2025 compared to 65 million in 2024.

The Octoverse is GitHub's annual report that tracks activity and growth across GitHub's user base and analyzes trends.

In an article on the GitHub blog, GitHub's CTO, Vlad Fedorov, stated that GitHub was not ready to handle the surge in traffic caused by AI coding tools:

While they planned for a 10x surge in traffic, the real need was closer to 30x. Although the quote says "since the second half of December 2025", indications of an increase in AI-coding related traffic were there earlier as stated in the Octoverse 2025 report.

The (Incomplete) Azure Migration​

GitHub's core platform migration to Microsoft Azure started in October 2025 and is still ongoing. Some components had already been migrated earlier. According the CTO's note, the "demands of AI and Copilot" have led to capacity constraints in its Virginia data center, and the move to Azure is necessary to keep up with the demands.

Although the Azure migration is often stated as a cause, it is more about how much of the migration is not completed. The migration, in the GitHub's CTO's words, will be prioritized over feature development to ensure there is sufficient capacity to handle the surge in traffic by both vertical and horizontal scaling.

In Mar 2026, only 12.5% of GitHub traffic was served from Azure.

Architectural Issues​

In GitHub's March 2026 official blog post, CTO Vlad Fedorov stated that the recent issues (in February and March 2026) were due to "rapid load growth, architectural coupling that allowed localized issues to cascade across critical services, and inability of the system to adequately shed load from misbehaving clients."

Root cause analyses of both the Feb 2nd and March 5th outages revealed single points of failure.

When GitHub Fails: Patterns in the Data​

Analyzing GitHub's downtime data reveals some interesting facts.

Severity Distribution (major vs minor)​

As you can see from the graph, the number of both major and minor outages has been increasing since December 2025.

Root Causes of GitHub Outages​

Pinpointing a single root cause in a distributed system outage is not always possible. We analyzed GitHub's outages from GitHub's own incident reports and categorized them by the primary stated root cause in the period of May 2025 to April 2026.

Capacity Issues​

A lot of GitHub's availability issues were due to load and capacity problems, accounting for 83 of the 257 outages. There are indications that capacity in many services did not automatically scale up to handle the load. Manual scaling up was required.

Examples:

Capacity issues also caused cascading effects:

Configuration Issues​

Bad configuration changes triggered many of the incidents. In distributed systems, such changes can have a cascading effect on other components as we saw in 2025's Cloudflare and GCP outages. Examples:

Infrastructure/Network Issues​

Network/Infrastructure issues are not always in GitHub's control, e.g. fiber cuts, power outages, etc.

Internal Issues​

The "internal" category includes outages caused by application bugs, kernel issues, etc.

Other causes ranged from insufficient pre-deploy checks as well as internal certificates expiring, causing downstream failures:

GitHub's Plan to Mitigate Future Outages​

These are based on the GitHub's public blog posts and post-mortem reports:

• Improve observability
• Improve automated detection
• Migrate more traffic to Azure
• Improve rollout safeguards
• Improve automatic mitigation

How GitHub Compares: GitLab & Bitbucket Reliability​

Methodology​

IncidentHub monitors GitHub, GitLab, and Bitbucket 24/7. Here's how they compare over the same 12-month period.

Incident Frequency​

GitHub had almost double the incidents as GitLab. However, these numbers do not take into account the number of projects hosted at GitLab or Bitbucket, and their traffic.

While no platform is perfect, GitHub's reliability has notably declined since December 2025.

The Real Cost of GitHub Outages​

GitHub hosts over 630 million projects contributed by 180+ million developers. Many of these projects are extensively used by businesses and organizations.

A GitHub outage can impact far beyond just developer productivity.

Productivity Loss​

• Unable to review Pull Requests
• Loss of productivity due to Copilot outages
• Blocked deployments and pipelines during Actions outages
• Lost work due to issues like the PR corruption incident

Business Impact​

• CI/CD pipelines down = no production releases
• Enterprise customers paying for unreliable service

Trust Erosion​

• Customers and businesses lose confidence after repeated outages in the same services

Conclusion: GitHub's Reliability Crisis​

The data clearly indicates that GitHub's reliability has declined significantly. GitHub's leadership has acknowledged the issues, and promised to prioritize reliability over feature development. However, the challenges facing them are on multiple fronts - an ever-increasing AI-driven traffic explosion, a partial Azure migration which needs to be pushed towards completion to handle capacity, and architectural issues.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This report is independent and not affiliated with or endorsed by GitHub, GitLab, or Bitbucket.

This article was first published on the IncidentHub blog.

You might also like:

• H1 2026 Cloud and SaaS Reliability Report
• The Definitive AWS Outage Report 2025: Reliability Analytics and Cascade Impact
• Major Cloud Outages of 2025
• GitHub Reliability - Current Status

IncidentHub tracked 48000 SaaS and Cloud outages in 2025. The average organization depends on 100+ SaaS apps, making third-party vendor monitoring a crucial aspect of risk management and business continuity for almost all modern organizations.

Better SaaS outage alerting is about monitoring the right parts of your third-party services, and routing alerts to the right people at the right time.

This article covers the six criteria that separate useful cloud outage alerts from noisy ones, how IncidentHub's alerting works, real-world scenarios where it matters, and who this tool is built for.

• The Alert Fatigue Problem in SaaS Dependent Teams
• Defining Good Third-Party Outage Alerting
  • Alert granularity - per-component, not per-service
  • Alert type filtering - suppress maintenance, mute noise
  • Lifecycle filtering - start, updates, resolution
  • Plug into existing workflows
  • Context-aware, tool specific alerts
  • Upcoming maintenance alerts
• How IncidentHub Delivers Smarter Cloud Outage Alerts
  • Per-service component filtering
  • Incident type filtering
  • Incident lifecycle filtering
  • Integrates into your existing toolchain
  • Context-aware, tool specific notifications
  • Upcoming maintenance reminders
  • Bonus: Your components first
• IncidentHub Monitors Every Service Your Stack Depends On, in One Place
• IncidentHub Alerting Capabilities at a glance
• Three Scenarios Where SaaS Outage Alert Quality Actually Matters
• Is IncidentHub the Right Outage Alert Tool for Your Team?
• Conclusion
• Frequently Asked Questions About SaaS and Cloud Outage Alerts

Defining Good Third-Party Outage Alerting​

What is good alerting for cloud and SaaS outages? There are plenty of tools and websites as of this writing which aim to show you the status of third-party services. However, a red or green status icon against a service name does not mean much if you are running a business. Google Cloud is down - but which Google Cloud components and in which zones? This is the bare minimum that a decent SaaS outage alerting tool should start with.

Alert granularity - per-component, not per-service​

Monitoring and getting alerts for an entire cloud platform when you use 5 services in 2 of its global zones is the road to alert fatigue.

Good alerting: Being able to choose which components, regions, services, etc. you want to monitor and get alerts for. Component-level filtering ensures you get only relevant alerts.

Alert type filtering - suppress maintenance, mute noise​

Many vendor status pages include both maintenance and outage alerts. While maintenance alerts are useful if you want to plan ahead, a lot of them are just noise for your team. Even when filtered through your component-level filtering, maintenance alerts can be too frequent or of no use to you.

The caveat here is that maintenance alerts for some of your services are useful, and some are not.

Good alerting: Being able to enable maintenance alerts for certain services, and turn it off for others.

Lifecycle filtering - start, updates, resolution​

Some services are more critical to your business than others. E.g. for an AWS-hosted application in EC2 us-east-2, you would want to be on top of every alert for EC2 incidents in that zone, including when it started, any intermediate updates as the incident progressed, and when it was resolved.

If you use Grafana Cloud for log ingestion, you don't need to receive every alert for an incident. Your team only needs to know if Grafana Cloud is down, and when it is back up, so that they can debug issues.

Good alerting: Being able to choose which lifecycle events you want to receive alerts for.

Plug into existing workflows​

Your team is already using a lot of tools. They have invested a significant amount of time to learn the ins and outs, short cuts, caveats of each. Putting another tool into the mix creates unnecessary friction and cognitive load.

Good alerting: Being able to send alerts to tools your team already uses, whether it's chat, email, paging, or a ticketing system.

Context-aware, tool specific alerts​

Workflow and communication tools are designed to make communication and collaboration easier through carefully designed interfaces and UX. An alerting tool should be able to adapt to the principles of its target tool when it integrates with one.

Slack automatically collapses large messages, and you can expand to read them fully. Third-party outage alerts can include the complete outage message, including the details, list of affected components, timestamp, link to the status page, link to the incident, and so on because your team is going to use that information to debug issues.

PagerDuty alerts are designed to be indicators, and they are just the initial trigger for an on-call engineer. Alerts either through the PagerDuty app or a phone call trigger a different workflow where the on-call engineer has to look at runbooks, dashboards, and other channels to respond to the incident. PagerDuty alerts for third-party services cannot be too verbose - they should be concise and to the point.

For IT and support teams working with ticketing systems like Zendesk, BoldDesk, and Atlassian Jira Service Management, it's important that there is an alert when a third-party service goes down, and there is no subsequent noise. The purpose of the initial ticket is to inform the team that AWS is down, or MS 365 is down, and leave them alone without sending updates for the same incident, so that they can deal with user tickets. They can always consult the aggregated status page that most aggregators provide to see when the service is back up.

Good alerting: Contextual, tool-aware alerts that are tuned by content and frequency.

Upcoming maintenance alerts​

Planning for maintenance is a routine part of your Ops/IT teams, and not just for your internal services. Knowing in advance when your third-party cloud services have maintenance windows is useful to plan for it.

Good alerting: Being able to receive alerts in advance for upcoming maintenance windows.

How IncidentHub Delivers Smarter Cloud Outage Alerts​

IncidentHub's SaaS outage alerting is designed to be granular, contextual, and tool-aware.

Per-service component filtering​

IncidentHub allows you to monitor exactly which components of a third-party service you are interested in. For example, if you are using Google Kubernetes Engine in us-east1 for your application, you can monitor only the Kubernetes service in that region. If your team uses Autotask, monitor only that instead of the entire Kaseya suite.

Incident type filtering​

IncidentHub's filtering allows you to turn off maintenance alerts, outage alerts, both, or neither on a per-service basis. This lets you have fine-grained control over each service.

Incident lifecycle filtering​

For each vendor that you monitor in IncidentHub, you can turn off intermediate outage updates - meaning that you will receive only start/end alerts for that service's incidents. This applies to all notification channels except ticketing systems.

Typically, vendor updates are sent at incident start, for each official status page update, and at incident resolution. This maps directly to the SRE/on-call workflow: know when to start investigating, stay informed as the vendor responds, know when to close the incident ticket. Most status page aggregators always fire on state change. IncidentHub follows the full narrative and allows you to control this for each service.

Integrates into your existing toolchain​

IncidentHub integrates with your existing communication tools. You can send cloud outage alerts to Email (including distribution lists), Slack, Microsoft Teams, and Discord - most commonly used team communication tools. PagerDuty is supported for on-call engineers. You can also hook up alerts to any custom system or dashboard using webhooks.

For your IT and customer support teams, IncidentHub can send alerts to ticketing systems like Zendesk, BoldDesk, Freshdesk, and Atlassian Jira Service Management.

Context-aware, tool specific notifications​

IncidentHub's SaaS outage alerts are designed to be contextual and tool-aware. This means that the alerts are formatted to be easy to read and understand by the target tool users.

A Slack, Microsoft Teams, or Discord alert has all the necessary information.

A PagerDuty alert is designed to be a simple indicator, whereas a webhook integration gives you the complete alert payload - and you can choose to filter that out further in your pipeline.

For ticketing systems, IncidentHub sends only the start event for an incident to avoid noise.

Upcoming maintenance reminders​

You can plan your internal operations better when you are reminded in advance of upcoming maintenance in your vendors. IncidentHub can send you reminders for upcoming maintenance. You can set the reminder to any time between 1-48 hours before the maintenance.

Bonus: Your components first​

Outages and maintenances are filtered against your component filters and only the matched alerts are sent. If the outage/maintenance has other components also in addition to your selected ones, they will show up too in the notification. To avoid confusing the user, IncidentHub bubbles up your chosen components to the top of the alert.

E.g. if you choose Cloudflare Worker and Pages in Cloudflare, and an outage occurs which affects Workers, Pages, and Workers Builds, you will see Workers and Pages at the top of the alert.

Together, these features make IncidentHub's SaaS and Cloud outage alerts better than other status page aggregators because they give you a 360-degree coverage of your third-party dependencies.

IncidentHub Monitors Every Service Your Stack Depends On, in One Place​

IncidentHub monitors 950+ services as of this writing, and new ones are being added regularly as well as on request.

Key categories that IncidentHub monitors are:

Monitoring all of these from a single dashboard, with a unified alert system and per-service component filters, is what makes IncidentHub a true cloud outage alert platform.

Don't see your service? You can request for specific services at our support email (support at incidenthub.cloud).

IncidentHub Alerting Capabilities at a glance​

Here's a full breakdown of IncidentHub's SaaS outage alerting capabilities and the problems each one solves:

Three Scenarios Where SaaS Outage Alert Quality Actually Matters​

Is IncidentHub the Right Outage Alert Tool for Your Team?​

When choosing a SaaS outage alerting tool, you should consider which is right for your team, and not which is the best.

Based on our experience, IncidentHub is a good fit for the following use cases:

• IT teams managing a portfolio of SaaS tools who need early warning without babysitting status pages manually.
• SRE and Ops teams who need cloud outage alerts to flow directly into their on-call workflows (PagerDuty, OpsGenie, custom runbooks) with enough granularity to act immediately.
• Development teams dependent on third-party APIs (Stripe, Twilio, OpenAI) where an upstream outage directly causes customer-facing failures.
• MSPs managing multiple clients, each with their own SaaS stack, who need a single dashboard per client with per-client monitoring configurations.

Conclusion​

The difference between good and great SaaS outage alerting is granularity: knowing which component in which service is down, routing only what matters, and doing it the moment an official status page update goes live.

The cost of a missed cloud outage alert is an incident your users feel before your team does. The cost of too many alerts is an on-call rotation that stops trusting the tooling, rendering it useless. A status page aggregator like IncidentHub can help you avoid both, and also keeps you informed about everything that is going on in your stack.

Frequently Asked Questions About SaaS and Cloud Outage Alerts​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

IncidentHub's latest product updates focus on improving the public status page, adding integrations with ticketing systems, private status page ingestion, and making the notifications more useful to the end user. Some of these improvements are driven by user feedback.

Feedback is what makes the product better, and I am personally grateful to all our customers who have shared their feedback with us.

• Introduction
• Maintenance Widget on the Status Page
• Private Status Page Ingestion
• Ticketing Systems Integration - BoldDesk and Freshdesk
• Notification Improvements
• Making it Easier to Debug Webhook Errors
• More Services

Maintenance Widget on the Status Page​

Your public status page now has a maintenance widget that shows your upcoming maintenance. It shows up at the top and you can see at a glance how many such events are scheduled. Like all other user facing dashboards and notifications in IncidentHub, the events are always filtered based on your component filters.

By default it's collapsed. You can click on it to expand it and see the details of the maintenance events.

Expanded view:

Note that the top summary bar shows the count of outages and ongoing maintenances, whereas the new collapsible widget shows your upcoming maintenances. Planning for upcoming maintenance in your cloud providers is crucial for your business continuity planning.

Private Status Page Ingestion​

You can now ingest status data from private status pages. Your cloud provider might give you an SSO-protected URL to access your private status page since the services are specific to your account. This is a powerful feature that allows you to track the status of your internal services and applications.

As of this writing IncidentHub supports private data ingestion from Infor CloudSuite. We will be adding support for more services in the future.

Ticketing Systems Integration - BoldDesk and Freshdesk​

Adding to our basket of ticketing system integrations which included Zendesk, we now support BoldDesk and Freshdesk too.

Ticketing systems notifications for third-party outages help your customer facing teams to stay on top of third-party outages and provide timely updates to your customers without surrendering to noise.

The key difference between ticketing systems and other notification channels is that IncidentHub sends only the trigger (start) event for any outage to ticketing system irrespective of your notification settings. It does not send notifications for ongoing or future maintenances, or for intermediate outage updates including resolution. This is to reduce noise for your support teams.

These are part of our upcoming Premium tier which is planned to be publicly available soon but they are already available to some of our customers on an invite-only basis.

Notification Improvements​

Choosing specific components in your monitored services is the way to avoid irrelevant alerts. Outages and maintenances are filtered against your component filters and only the matched notifications are sent. If the outage/maintenance has other components also in addition to your selected ones, they will show up too in the notification. This can sometimes be confusing for the end user.

We have tweaked the notifications experience slightly so that your chosen components bubble up to the top of the alert.

E.g. if you choose Cloudflare Worker and Pages in Cloudflare, and an outage occurs which affects Workers, Pages, and Workers Builds, you will see Workers and Pages at the top of the alert.

This is automatically done for all notification channels.

We are always eager to improving this further. Please let us know if you have any feedback on this using our support email address.

Making it Easier to Debug Webhook Errors​

Currently, if you have a webhook integration with IncidentHub, and there is an error in the webhhook, IncidentHub sends out a notification email to the account owner. While this is helpful as a notification, it does not help when you are debugging the integration. You can use the Test button to send a test alert - but if it fails, until now, there was no clear message on what went wrong.

Based on user feedback, we have added the ability to see the actual error. This happens in two cases:

• When you click "Send a test message" it will show you the error message in the popup.

• When the webhook has failed previously in the background while trying to send notifications, there will be a red indicator with a "View Details" next to the webhook.

It will show the last seen failure message and the log time.

More Services​

We have added support for more services including telecom providers, electricity/utility companies, crypto exchanges, and MSP tools. This adds to our constantly growing list of supported services.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All the logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

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.

• Introduction
• Methodology
• Frequency of Outages
• Duration of Outages
• Outages by Service
  • Services Affected per Outage
  • Services Which had the Highest Number of Outages
  • Regions with the Highest Number of Outages
• Is Reliability Improving, Staying the Same, or Getting Worse?
• Outage Dependency Mapping
  • Cascading Outages Timeline
  • Dependency Outages by SaaS Type
    • Observability and Incident Management Providers
    • Developer tools
    • Infrastructure and Hosting Providers
    • IT Operations and MSP Tools
    • Education Technology Platforms
    • Payments
• Regional Outage with Global Impact
  • Outage Chains
• Surviving AWS Outages
  • Reconsider if us-east-1 is necessary for your workloads
  • Audit your own dependency chain
  • Monitor third-party dependencies, not just AWS directly
  • Accept that multi-cloud is not a silver bullet
• Conclusion
• FAQ

Methodology​

We collected and analyzed the uptime of all AWS services and regions for a period of 1 year between 1st January 2025 and 31st December 2025. In this period, IncidentHub - status page aggregator - detected 38 outages across AWS products and regions. To detect cascading outages, we filtered out incident reports from SaaS vendors who acknowledged the cause as AWS on their status pages.

For this report, an "outage" is defined as an incident listed on AWS's status page that impacts or disrupts at least one AWS service. Each AWS status page incident was counted as a single outage, regardless of the number of services or regions listed.

We analyzed only 2025 incident data here.

We wanted to keep the analysis relevant to practitioners - actual users who rely on AWS. We focused on these aspects:

• Frequency of outages
• Duration of outages
• Outages by Service and Region
• Is Reliability Improving, Staying the Same, or Getting Worse?
• Outage Dependency Mapping - Which other SaaS providers were affected?

Frequency of Outages​

AWS had at least one outage every month except for the last two in 2025. For a platform as large as AWS, this is not surprising. However, the real measure of reliability is the duration and the impact of the outages.

Duration of Outages​

The shortest outage lasted around 14 minutes, whereas the longest was around 15 hours.

Average monthly MTTR was higher in Q3 than in Q1 and Q2. The October 20th outage being an outlier drove up the MTTR to be almost 12x that of January's in Q4.

Outages by Service​

There is usually no correlation between the number of affected services and the duration of the outage in most of the outages, except for the one on Feb 13th and on Oct 20th.

Services Affected per Outage​

Services Which had the Highest Number of Outages​

Regions with the Highest Number of Outages​

The AWS us-east-1 region recorded the highest number of outages in 2025. This has been variously attributed to it being the oldest, busiest region, as well as many control plane services being hosted there. E.g. the IAM service, Cloudfront, and Route 53's control planes are in us-east-1.

However, for the 20th October 2025 outage, the number of affected services in us-east-1 was high because a core service - DynamoDB - on which other AWS services depend, was affected in us-east-1 due to a race condition in its DNS management system as Amazon explains in their detailed summary. DynamoDB runs in other AWS regions too - so this outage could have theoretically happened in other regions as well. The AWS team rolled out the fix for the race condition to the first region by October 24th and by October 28th they had it across all regions worldwide.

Is Reliability Improving, Staying the Same, or Getting Worse?​

A quick look at service-wise outages for some of the top-10 services affected shows variable trends. However, overall for AWS as a whole, the average monthly outage duration increased in Q3 compared to Q1 and Q2, but the number of services affected decreased (except for the Oct 20th outlier).

Outage Dependency Mapping​

The AWS outage of Oct 20th was one of their biggest outages in 2025. In distributed systems, failures in one part of the system can result in cascading failures in other parts of the system. The same principle applies to SaaS providers and their dependencies. A lot of key AWS services were affected, and as a result, many SaaS providers. Since many SaaS providers use AWS directly and also other SaaS providers which in turn use AWS, the overall impact multiplied rapidly.

IncidentHub detected 400+ other SaaS outages in the same timespan as the AWS outage of the 20th - out of which 197 SaaS providers acknowledged the cause as AWS. The subsequent analysis takes only those 197 SaaS providers into account, although it's highly likely the blast radius was much larger.

Note: The numbers are smaller than what somebody would expect the expected blast radius to be because:

1. There are services that IncidentHub does not monitor yet.
2. Not all affected services monitored by IncidentHub acknowledged the cause as AWS.

Cascading Outages Timeline​

The graph below shows the number of outages in SaaS providers over time who acknowledged the cause as AWS. After AWS resolved the issue, it took time for some services to recover - this is expected due to their validating recovery measures and their reliance on direct or indirect dependencies which were themselves recovering.

Dependency Outages by SaaS Type​

The top SaaS categories affected included Cybersecurity tools, Developer tooling, Communication and Collaboration tools, Education Technology Platforms, and CRM, Marketing, and Customer Support.

Notably, Observability and Incident Management tools also appear in the distribution - the very tools that teams rely on to detect outages.

Let's look at some of these categories in more detail.

Observability and Incident Management Providers​

Observability data ingestion was affected in DataDog, Dynatrace and New Relic. As a result, monitoring systems in SaaS that use such data for alerting and incident management were affected.

Incident Management software were also affected - some directly, some indirectly. Efforts to move to another AWS region were made in some cases but it took hours. On call notifications were delayed or not sent at all.

Essentially, during the outage, visibility into your systems was impaired if you were dependent on SRE/Ops tools that use AWS in some way.

Developer tools​

Developer tooling took a significant hit, with several platforms reporting outages well in excess of 20 hours - disrupting CI/CD pipelines, code review, and feature flag management simultaneously.

Outages in artifact repositories and container registries affected downstream services like managed Kubernetes platforms that depend on them.

Infrastructure and Hosting Providers​

Core infra services like some DNS providers were affected - leading to DNS propagation delays. Other cloud providers who depend on SaaS that use AWS saw impact on some of their services.

Hosting platforms Netlify and Render were down for 13+ hours, affecting websites running on them. DigitalOcean reported that their managed Kubernetes platform was affected due to Docker Hub issues, which were due to AWS, for 19+ hours.

IT Operations and MSP Tools​

IT Ops and MSP tools were significantly affected, with several tools managing remote devices and endpoints remaining down for over 13 hours.

Education Technology Platforms​

More than 13 education technology platforms reported outages, some lasting well over a day.

Payments​

Outages in payments providers mean lost revenue, and there were plenty of them.

Although there were services which acknowledged that they managed to failover to another region, the lag in recovery across many SaaS vendors suggests that region-level failover is not straightforward in practice.

Regional Outage with Global Impact​

Was this a regional AWS failure that also took down global services? Yes, in some cases, by extension. The AWS failure itself remained regional.

This happened due to second and third, and more, order effects:

Outage Chains​

It's not straightforward to map a complete dependency graph of all the services that were affected by this outage, but we did manage to uncover some interesting aspects.

Here are 3 chains we uncovered, each showing how a vendor's outage was not triggered by AWS directly, but by another vendor's outage that depended on AWS - illustrated by incidents at StatusHub and Railway.

Upstream dependencies cannot be avoided. Even with a multi-cloud approach - which itself is not straightforward and may not be feasible architecturally or financially for everyone - key dependencies can remain tied to single providers.

Surviving AWS Outages​

Reconsider if us-east-1 is necessary for your workloads​

The us-east-1 region is the oldest and busiest in AWS, and it saw the highest number of outages in 2025. Even though the biggest one in 2025 could have occurred in any region, us-east-1 still leads in the total number of outages. You have no control over the control plane and global services that run there, so you can avoid us-east-1 if your workloads can run in other regions.

Audit your own dependency chain​

First level dependencies for AWS are easy to find. Second and further level ones are not so easy. However, listing down all your dependencies is a great first step.

Monitor third-party dependencies, not just AWS directly​

Tools like status page aggregators can monitor third-party dependencies seamlessly, without the need to manually check each and every status page or account for any differences in their structure or notifications. Monitoring the specific components you use (e.g. EC2 in AWS) is necessary to keep your alerts relevant.

Accept that multi-cloud is not a silver bullet​

Multi-cloud sounds like an attractive proposition until you realize that:

• It may not be feasible for your organization either architecturally or financially.
• Your other SaaS dependencies may not be multi-cloud and thus won't be as resilient.

The first step is knowing when your dependencies are down.

Conclusion​

2025 showed us that an infrastructure provider outage can cascade across hundreds of dependent services and that was true for AWS too. 38 outages were recorded across 200+ products and 39 regions. Most AWS outages in 2025 remained confined to a single region. The October 20th outage led to many downstream SaaS providers experiencing outages too.

Layers of downstream dependencies amplify a single provider's outage. Monitoring your SaaS dependencies is more crucial than ever to stay ahead of the impact such outages can have on your business.

FAQ​

Photo by Scott Rodgerson on Unsplash

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. Amazon Web Services and AWS are trademarks of Amazon.com, Inc. This report is independent and not affiliated with or endorsed by Amazon.

This article was first published on the IncidentHub blog.

You might also like:

• H1 2026 Cloud and SaaS Reliability Report
• GitHub Outages 2025 - 2026: Reliability Analysis and Outage History
• Major Cloud Outages of 2025

This is an updated and expanded version of the older guide.

According to the 2025 State of SaaS report, organizations use an average of 106 SaaS apps.

Staying on top of your SaaS vendors' status is as important as monitoring your own services. The Cloudflare, AWS, Azure, and Google Cloud outages in 2025 were strong reminders of this fact. As a result of these outages, many SaaS services that depend on them experienced outages as well, leading to a cascading effect which took down hundreds of vendors and affected thousands of users. Cloud and SaaS outages are not isolated any longer but usually happen in groups due to the dependency chain.

This article aims to be a comprehensive guide on how to monitor the uptime status of your SaaS and Cloud vendors.

• Introduction
• Monitoring SaaS and Cloud Vendors' Status
  • How to Monitor Multiple SaaS Status Pages - Quick Overview
  • Why Status Pages Remain the Gold Standard
• Manual Monitoring of Public Status Pages
  • Locate the Public Status Pages
  • Understand the Status Page Structure
  • Configure Notifications if Available
    • Notification Challenges
  • Subscribing to Status Page RSS Feeds
• Running Your Own Status Page Monitor
• Using a Status Page Aggregator
  • Key Benefits of Managed Status Page Aggregators
  • Status Page Aggregator Best Practices
    • Set up Component Filtering
    • Fine-tune Alerts by Type
    • Fine-tune Alerts by Lifecycle
    • Integrate with Your Team's Workflow
    • Include Third-party Status in Your Incident Response Plan
    • Periodically Review Your Organization's Service Usage
    • Make the Aggregated Status Page Easily Accessible
    • Enable Upcoming Maintenance Notifications
  • Advanced Techniques with a Status Page Aggregator
    • Automate Ticket Creation
    • Setup Multiple Teams
    • Custom Integration Using APIs and Webhooks
    • Historical Trend Analysis
• Choosing Your Monitoring Approach
  • Decision Table
• A Status Page Aggregator Implementation Workflow
  • Implementation Workflow Overview
  • Discovery
  • Team Setup
  • Monitoring Configuration
  • Alerting Configuration
  • A Single Status Page for Many Status Pages
  • Integration Into Incident Response Plan
• Common Status Page Aggregator Implementation Pitfalls
  • Starting With Too Broad Settings
  • Accessibility and Visibility
  • Stale List of Monitored Services
• Non-Status Page Methods
  • Using Third Party Telemetry Data Sites
  • Using Crowdsourced Information Sites
  • Using Social Media
• Conclusion
• FAQ

Monitoring SaaS and Cloud Vendors' Status​

There are several ways to monitor SaaS and Cloud vendors' status. The most reliable one is to monitor their public status pages. Status pages remain an important source of truth as they are directly managed by vendors. There are other, supplementary sources of information apart from status pages that you can refer to, but they are neither comprehensive nor always reliable.

We will look at each of them in turn.

If you want a quick way to decide which approach fits your situation, jump to the decision table later in this guide.

How to Monitor Multiple SaaS Status Pages - Quick Overview​

To monitor multiple SaaS and cloud service status pages in one place, you have these options:

1. Manually check each vendor's public status page (not scalable beyond a few vendors).
2. Subscribe to individual email/RSS notifications (no component filtering, fragmented alerts).
3. Build and maintain your own status page monitor (high effort, high maintenance).
4. Use a status page aggregator that combines multiple status pages into a single view (recommended).

Why Status Pages Remain the Gold Standard​

Status pages are directly managed by vendors, and are hence authoritative sources of information. They also have structured, parseable data that can be consumed by automation tools. They remain the contractually significant source for tracking SLAs.

In some cases, vendors may take longer to update their status pages to announce an incident that they are still investigating. This reflects their internal incident response process. While crowdsourced platforms and telemetry data sites may provide early warnings, such sources lack context (which components, regions are affected), accuracy, and official confirmation.

The reason status pages remain essential is because they provide structured incident data, regional and component level details, official timelines for SLAs, and upcoming and ongoing maintenance schedules.

Manual Monitoring of Public Status Pages​

Manual monitoring works only at a very small scale and is included here to establish a baseline for comparison.

The first step here is obviously to identify the SaaS and Cloud vendors that you use. Once you have listed them, drill down into the specific services and regions that you use. Note that not all methods we describe in this article support monitoring specific services and regions.

Locate the Public Status Pages​

Most third-party services have a publicly available status page. You can usually find the link on their company website or on their support portal. The status page is either directly managed by your SaaS vendor or outsourced to another service like Atlassian Statuspage, Instatus, Hund, StatusCast, StatusHub, etc. Many monitoring and incident management services like Incident.io and BetterStack also have public status pages as part of their observability and incident management products.

Large cloud platforms like Google Cloud, Amazon Web Services, Microsoft Azure, Hetzner etc. have their own status page software.

Understand the Status Page Structure​

There is no official standard for status page formats but most of them use a similar layout to present the most important information - the current status - first. Visual appeal, ease of use, reliability, timely and useful information, and accessibility are important considerations for public status pages.

Some status pages segregate ongoing incidents into maintenance and outages. Upcoming maintenances are listed so that users can prepare for them.

Screenshot from the Zscaler status page.

Common terms used to describe incident states are:

• Investigating
• Identified
• Monitoring
• Resolved

although these can differ from page to page.

Configure Notifications if Available​

Periodically visiting status pages to check is not a great practice and is impossible once you start to monitor more than a few. Instead, you can choose to sign up to receive notifications when there is an incident created, updated or resolved. Depending on your provider, status pages offer different modes of notification.

Some status pages have only one or two options, or none at all. E.g. The Salesforce status page has only email notifications:

Screenshot from the Salesforce status page.

If the status page is managed by someone other than your cloud provider, your cloud provider can choose to enable/disable some of the available notification options. For an example, both OneWelcome and Ongoing use Atlassian Statuspage but the notification options (as of this writing) are different.

Screenshot from the OneWelcome status page.

Screenshot from the Ongoing status page.

Notification Challenges​

Your notifications should be delivered in a way that ensures the right team receives the alerts. To be able to make it part of your team's workflow, the status page should support the notification channels that your team uses. Your vendor status pages won't have homogeneous notification options, which becomes an obvious hurdle here. They might not offer the option you need. See the section on Using a Status Page Aggregator on how to mitigate this.

Also, there is no way to test these notifications until the next outage happens.

If you are manually monitoring status pages, you can check if the status page supports filtering by components and regions. If it does, use it so that your team is not flooded with unnecessary notifications.

Subscribing to Status Page RSS Feeds​

Some vendor status pages have RSS feeds that you can subscribe to. You can pipe the RSS feed into your Slack, Discord, or MS Teams channel. While this gives you a good way of getting outage information directly from the vendor, it has several drawbacks:

• Not all status pages have RSS feeds.
• This approach lacks any filtering for components and regions. You will end up receiving every single outage and maintenance notification.
• There is no way to search through historical data easily or look at ongoing incidents and maintenance.
• There is no single view of all your services in a single place. The alerts will be in your Slack or Discord or MS Teams channel.
• Some RSS feeds won't notify you when an incident is resolved.
• This approach can break easily when your vendor changes status page providers as the RSS feed URL might change or get removed completely. Your team would stop receiving notifications and would not know about it until it's too late.

In short, subscribing to RSS feeds does not hold up as a solution for staying on top of outages both because of the sheer variety of status pages that are out there and also because of the limitations of the RSS feeds themselves.

Running Your Own Status Page Monitor​

There are some open source tools that attempt to monitor third party status pages. However, they are not full-fledged solutions.

• statusphere : This is not being actively developed. As of this writing the last commit was in 2024.
• status-page-aggregator : According to the README, it is a "A production-ready status monitoring dashboard that SRE teams can fork and customize for their specific vendor dependencies." However, it lacks out of the box notification support except for email. There is also no way to choose specific vendors to monitor.
• statusy : This repository is also archived and not being developed any longer.

Such tools may not support all the services or features you need. There is also no guarantee of them being bug-free, or of getting support when you need it. Hosting your own monitor from an open source project has almost the same level of effort as developing and maintaining your own in-house tool. That comes with its own challenges of engineering cost, maintenance, new service support, reliability, and uptime. In addition, there are technical challenges in maintaining such a tool:

• Some status pages without any RSS feed or APIs need to be scraped. HTML scraping can easily break when the status page layout changes.
• Many status pages have CAPTCHA/bot protection to prevent abusive behavior. If your status page monitor tool does not have the correct logic to prevent such behavior, it can easily get blocked from further data collection.
• All status page providers enforce rate limiting for API requests. If your tool does not respect these limits, it will be blocked from further API calls.
• Vendors moving to new status page providers can break your status page parsing as the API endpoints will change.

Using a Status Page Aggregator​

A status page aggregator periodically tracks multiple status pages and centralizes third-party dependency status in one page. It presents a single status page for multiple other status pages by combining and normalizing data from them. The data is fetched using different methods including RSS feeds, APIs, scraping, and webhooks.

Screenshot from an IncidentHub public status page.

IncidentHub is a status page aggregator built specifically for monitoring third-party SaaS and Cloud status pages.

Key Benefits of Managed Status Page Aggregators​

A managed status page aggregator:

• Normalizes external data sources (status pages, APIs, RSS feeds, webhooks) that differ in format and terminology.
• Gives you one status page for multiple other status pages.
• Adapts to changing status page formats, URLs, and providers.
• Supports advanced alert filtering and notification options not available on the status page.
• Lets you analyze historical data and availability trends.
• Supports multiple users and teams which is useful for large organizations.

Status Page Aggregator Best Practices​

Set up Component Filtering​

An outage alert is relevant only if it directly affects your business in some way. Instead of receiving alerts for each and every incident from a vendor, you can select the specific components that your organization actually uses. This prevents alert fatigue and keeps your notifications relevant.

Fine-tune Alerts by Type​

You can further fine-tune alerts by type. You can set up your status page aggregator to send notifications only for outages, only for maintenances, or for both. E.g. For some services like Twilio, there are a ton of maintenance events which might not be relevant for your needs even if they are filtered by component.

Fine-tune Alerts by Lifecycle​

Some third-party services are more critical than others for your business. You would want to closely follow every outage update for those until it is resolved. For not so critical services, it is okay to receive alerts only when the outage start and ends. Some status page aggregators let you toggle this.

Integrate with Your Team's Workflow​

The easiest way to onboard a new tool is to integrate it with your team's existing processes. A status page aggregator can send notifications to whatever your team uses - Slack, Discord, Email, Microsoft Teams, etc. to stay ahead of outages.

Include Third-party Status in Your Incident Response Plan​

Including third-party service status in your incident response plan helps correlate alerts from your own systems with alerts from third-party services. This can help your team triage incidents faster. E.g. when you receive an alert for your payment processing microservice that talks to Stripe, you can quickly check Stripe's status and rule out external issues.

Periodically Review Your Organization's Service Usage​

You can do this as part of your incident response plan review. Your organization may start using new services, stop using existing ones, or start using new services on the same vendor's platform. This should be reviewed periodically to ensure that your status page aggregator's monitored services are in sync with your organization's usage.

Make the Aggregated Status Page Easily Accessible​

A centralized status page with all your services and vendors' status gives you at-a-glance visibility into the status of your third-party dependencies. You can display it on a large screen TV or monitor in your office. Many NOC teams do this. This can help your team stay on top of outages easily even if you have alerts enabled.

Enable Upcoming Maintenance Notifications​

Some status page aggregators let you enable upcoming maintenance notifications so that your team can prepare for them. This can avoid last-minute surprises when the maintenance is about to start.

Advanced Techniques with a Status Page Aggregator​

Automate Ticket Creation​

Your customer support team can respond proactively to customer inquiries about outages in your products if they are aware of third-party outages that might be the root cause. If your status page aggregator integrates with platforms like Zendesk, it can automatically create tickets there and keep your support team informed.

Setup Multiple Teams​

In larger organizations, different teams may have different third-party dependencies. They may use different services, or different components from the same service. The alerting needs may also be different - with each team being in, say, a different Slack channel. Such cases are best handled by creating multiple teams and segregating the aggregate status pages and alerts by team. Each team can also be managed by different admins and include different team members. This way, services, alerts and status page remain separated by team, while the overall data and settings remain under a single organization account.

Advanced status page aggregators support this by letting you setup multiple teams and individual status pages and alerts channels for each.

Custom Integration Using APIs and Webhooks​

If you have custom-developed or legacy tools for alert notifications, or have a custom dashboard for incident management, the standard integrations in a status page aggregator may not be enough. You can use the aggregator's APIs and webhooks instead to push the outage and maintenance updates to your tool/dashboard.

This preserves a seamless experience for your team where they continue to use their existing tools and can see their third-party dependencies' status in the same place.

Historical Trend Analysis​

You can track historical data for your dependencies to see how often they go down and identify patterns. This can also help you to:

• Validate SLA commitments for contract renewals.
• Make data-driven decisions when you select vendors.
• Identify services that are unreliable but critical and justify backup vendors for redundancy.

Data source: IncidentHub monitoring

Choosing Your Monitoring Approach​

Your approach depends largely on your scale and needs. However, given that most teams today - irrespective of size - depend on third-party services, a status page aggregator is usually a hassle-free option. It can scale with your needs.

If your needs are really simple, then you may not need an aggregator - e.g., if:

• You have one or two third-party dependencies.
• All your status pages allow you to filter by components.
• All your status pages support your alerting channels.
• You are not interested in seeing an overall status page for all your status pages, and alerts in email/Slack/Discord are enough.
• You don't need to fine-tune alerts by type and lifecycle.
• No need for historical trend analysis.

Decision Table​

A Status Page Aggregator Implementation Workflow​

A typical workflow for integrating a status page aggregator into your organization would have the high-level steps outlined below.

Implementation Workflow Overview​

Status Page Aggregator Implementation Workflow diagram

Discovery​

List down your third party services and their components/regions that you use. If you have multiple teams, you need to do this separately for each team. If you have different levels of criticality for your services, you need to categorize them accordingly. These settings will be used to configure the alerts later - see the sections Component filtering, Fine-tune Alerts by Type, and Fine-tune Alerts by Lifecycle.

If you have services with a lot of components (e.g. like Cloudflare, Google Cloud Platform, etc), you can directly configure the aggregator instead of listing them down first. It is helpful, however, to have the list of vendors in one place. You may be able to get the vendor list from your compliance or security team. For smaller organizations, you might have to compile this yourself. Other sources can be:

• Billing and procurement systems.
• IT asset inventory.
• Team surveys.

Team Setup​

Create individual teams in the aggregatorif you have more than one team and each team has different needs for dependencies and alerting. Each team can have one or more admins and team members if the aggregator supports it.

Monitoring Configuration​

If you have multiple teams, add the monitored services and components/regions for each team in the status page aggregator. You can further fine-tune the alert types if required. For a single team, the setup is much simpler.

Alerting Configuration​

Integrate the alerts with your team's existing tools - Slack, Discord, Email, Microsoft Teams, etc. Some status page aggregators like IncidentHub let you send a test message to ensure that your integration is working fine.

A Single Status Page for Many Status Pages​

Set up the single status page, or one for each team (if you have multiple teams). This will be the single point of truth for your team to see the status of all their services. Depending on the status page aggregator, you can whitelabel the status page with your own logo, brand colors, custom domain, and other branding elements. You can also add a password to the status page to prevent unauthorized access.

Integration Into Incident Response Plan​

Include third-party status monitoring in your incident response plan. Your on-call engineers should be able to access and understand the aggregated status page and the alerts. Make this a part of your on-call training and awareness programs.

Common Status Page Aggregator Implementation Pitfalls​

Here are some common pitfalls to avoid.

Starting With Too Broad Settings​

Enabling all alerts can overwhelm your team and easily lead to a state where they start to ignore alerts. Choose your filters and other settings carefully so that you are not flooded with unnecessary alerts. It might take a few iterations to get this right.

Accessibility and Visibility​

The on-call teams, developers, Ops and IT teams should be able to use this information to triage ongoing outages. The dashboard and alert channels should be easily accessible and visible.

Stale List of Monitored Services​

Services, regions, vendors get added/removed/changed frequently. The list of monitored services should be updated regularly to avoid stale information as part of your incident response plan reviews.

Non-Status Page Methods​

These methods are included here for completeness. They are not as comprehensive as the status page monitoring approaches and are not recommended for serious use cases.

Using Third Party Telemetry Data Sites​

DataDog, the observability and monitoring platform, recently announced a site called updog.ai. It curates data from DataDog's own customers who monitor their infrastructure using DataDog. While this can be a limited early warning system, it does not suffice as a comprehensive monitoring solution:

• It is limited to the vendors that DataDog's customers monitor. E.g. cloud vendors like AWS are present, but IT management software like Kaseya are not. This is understandable as the data mostly comes from users who use cloud and SaaS services to run their applications. As a user you have no control over the telemetry - which is necessarily constrained by which services, regions, or components of a given cloud service DataDog's customers monitor.
• There is no way to monitor specific services and regions and view them on a single dashboard. E.g., you can filter AWS services but you have to visit each service's page on the Updog website to see its status.
• There is no way to receive notifications from the Updog website when a service is down.

Using Crowdsourced Information Sites​

There are numerous sites like Downdetector which rely on user reports to aggregate information about service outages. By definition, outage reports on such sites are not comprehensive and neither do they provide a holistic view of the outage:

• User reports can have false positives. E.g. ISP issues interpreted as service outages.
• If users don't report an outage for a specific region, or a service, that's a gap in the coverage.

Such sites also do not provide a way to receive notifications when a service is down, or let you create your own single status page.

Using Social Media​

Social media like X, Bluesky, Mastodon, Reddit, Hacker News etc. are the first place people often check for outage reports or post asking for information. Such reports can be helpful to know that something might be off with a service, but they cannot be relied upon for the same reasons as the previous point about crowdsourced information.

Some services have an official social media account, but most don't. For example, Microsoft 365 has an official X account where they announce service outages.

Screenshot from the Microsoft 365 status account on X.

Conclusion​

2025 saw a number of major cloud outages, especially in the infrastructure layer, demonstrating the impact that a few providers can have on other services and users. It is more critical than ever to monitor your third-party dependencies' status. A managed status page aggregator is the most comprehensive way to do this.

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

You might also like:

• Six IsDown Alternatives in 2026
• Vendor Outage Monitoring for MSPs
• Top 6 Reasons Why You Need a Status Page Aggregator

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.

• Cloud Outages and Their Impact
• Major Cloud Outages in 2025
  • Microsoft Azure - 8 January
  • Slack - 26 February
  • PagerDuty - 26 February
  • OpenAI - 8 April
  • Zoom - April 16
  • Google Cloud Platform - 12 June
  • Microsoft Azure - 6 September
  • Google Workspace - 18 September
  • Amazon Web Services - October 20
  • Microsoft Azure - 29 October
  • Cloudflare - November 18
  • OpenAI 26 November
  • Cloudflare - December 5
• The Impact of Infrastructure Provider Outages
• Using A State Page Aggregator to Monitor Cloud Outages
• Conclusion

Major Cloud Outages in 2025​

Microsoft Azure - 8 January​

A networking configuration change in East US2 caused "connectivity issues, prolonged timeouts, connection drops, and resource allocation failures" across multiple Azure services. Loss of indexing data in the Azure PubSub service - which is used by the networking control plane to communicate between control entities and agents on individual hosts - caused networking configuration to not be delivered to the agents. The outage lasted around 50 hours.

It's noteworthy that the RCA report mentions that "Services that were configured to be zonally redundant and leveraging VNet integration may have experienced impact across multiple zones." The RCA also mentions a step to prevent this in future outages.

Link to incident: https://azure.status.microsoft/status/history/?trackingId=PLP3-1W8

Slack - 26 February​

An outage in the Slack Events API caused custom applications, integrations, and bots to not work as expected. This outage was traced to the mitigation steps taken to resolve an earlier incident. This lasted around 25 hours.

Link to incident: https://slack-status.com/2025-02/d41e4bfd1ccae26a

PagerDuty - 26 February​

Slack integration for PagerDuty was affected due to an outage in Slack (see above). Users who depend on PagerDuty applications for Slack were unable to receive notifications. With Slack becoming more and more popular as a central tool in incident management, this outage disrupted the workflow for many teams, including those who did not use the PagerDuty application.

This is a classic example of an incident notification tool itself being affected by an incident - in this case, on a dependent provider. PagerDuty notes in its future improvement points that it will work on "Improving our monitoring to ensure that we can respond faster to issues with our integration partners" and also to figure out other ways of improving the user experience in such cases.

Link to incident: https://status.pagerduty.com/posts/details/PB5WBMB

OpenAI - 8 April​

OpenAI ran into capacity issues while handling requests for Sora, its sophisticated video generation model. To mitigate the problem, OpenAI rolled out Sora capabilities in the same order that users signed up for it. The issue was officially marked as resolved on 30th April - around 22 days after it was reported.

Link to incident: https://status.openai.com/incidents/01JRB888M6TJVDDKGCA1YZ3ZHT

Zoom - April 16​

This started as a domain resolution failure when the zoom.us domain was blocked by its registrar. The TLD nameservers stopped resolving the domain as well as all its subdomains. This outage officially lasted around 1 hour 47 minutes, and received a lot of publicity due to Zoom's widespread usage.

Link to incident: https://www.zoomstatus.com/incidents/pw9r9vnq5rvk

Google Cloud Platform - 12 June​

Affecting mainly Google Cloud services and a handful of Google Workspace services, this outage was caused by a bad automated update to Google Cloud's quota check system. The update propagated globally, affecting external API requests and impacting many products.

The incident lasted around 3 hours. 76 different Google Cloud services were affected.

Link to incident: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

Microsoft Azure - 6 September​

Multiple undersea cable cuts in the Red Sea caused widespread disruption to global communications passing through Azure's network.

As a workaround, Microsoft Azure rerouted traffic through alternate paths.

Link to Hacker News discussion: https://news.ycombinator.com/item?id=45152773

Google Workspace - 18 September​

A resource contention issue in Google's authentication system caused login failures across many Google services. It was mitigated by increasing the available capacity.

The outage lasted 1 hour 13 minutes. Due to the key nature of the affected service (authentication), users were unable to access other services, increasing the blast radius of the outage.

Link to incident: https://www.google.com/appsstatus/dashboard/incidents/5V5yK8N8heBKnmdqS1eW

Amazon Web Services - October 20​

A race condition in Amazon's DynamoDB's DNS caused prolonged impact in other AWS services in us-east-1. Many AWS services depend on DynamoDB internally. 141 services in AWS were affected by the outage.

Link to post-incident write up: https://aws.amazon.com/message/101925/
Another interesting video on this https://www.youtube.com/watch?v=YZUNNzLDWb8

Microsoft Azure - 29 October​

A series of customer configuration changes resulted in incompatible metadata being generated in Azure's Content Delivery Network. "This configuration (with the incompatible metadata) completed propagation to a majority of edge sites by 15:39 UTC.", according to the report. Although their internal config protection system caught the impact when it became visible, and stopped all new and inflight configuration change requests, the bad configuration was already processed by the edge server.

Link to incident: https://azure.status.microsoft/status/history/?trackingId=YKYN-BWZ
A video retrospective: https://www.youtube.com/watch?v=PHvIYrWkAJU

Cloudflare - November 18​

Cloudflare's network experienced an outage starting at around 11:20 UTC. Since this affected Cloudflare's Sites and Services, it resulted in thousands of websites being rendered inaccessible, thus multiplying the impact. A database permission change caused a larger than expected file to be fed into Cloudflare's Bot Management System, causing it to crash. This change was propagated all over the world, repeating the pattern we have seen in other outages where one bad change is replicated across the global network.

Link to incident: https://www.cloudflarestatus.com/incidents/8gmgl950y3h7
Analysis: https://blog.cloudflare.com/18-november-2025-outage/

OpenAI 26 November​

Both OpenAI APIs and ChatGPT were affected by control plane failures in some of OpenAI's GPU clusters. The failure was caused by a global change to Kuberenetes namespace labels.

Link to incident: https://status.openai.com/incidents/3pn6gclf1cjx

Cloudflare - December 5​

Cloudflare's dashboard and related APIs were affected by a change that was deployed to mitigate a React Server Components vulnerability.

Link to incident: https://www.cloudflarestatus.com/incidents/lfrm31y6sw9q
A detailed write up: https://blog.cloudflare.com/5-december-2025-outage/

The Impact of Infrastructure Provider Outages​

In the second half of 2025, 3 outages caused major disruption, demonstrating once again that the lower the service in the stack, the larger the blast radius of the outage. Cloudflare (twice), Azure, and Amazon Web Services affected thousands of downstream cloud and SaaS services and customers.

An infrastructure outage can affect other services like dev tools and authentication providers. An authentication provider outage can affect other services like a remote monitoring tool in turn.

This is also reflected in the rise in outages in September, October, and November, when we saw Azure, AWS, and Cloudflare go down.

Data source: IncidentHub's monitoring of public status pages.

Overall, cloud provider outages remain the second highest category of outages in 2025, after cybersecurity providers.

Data source: IncidentHub's monitoring of public status pages.

There is also another pattern in infrastructure provider outages. Such services use their own internal distributed infrastructure to propagate changes globally to control plane software like agents in other regions. A bad change will propagate with the same speed as a good one:

Thus, the impact of such bad changes is not local and spreads quickly.

Each outage remains an opportunity to to improve processes. Most large cloud providers are proactive in sharing detailed technical root causes of outages.

Last but not the least, an outage is an extremely stressful experience for the folks on-call, especially when there are thousands of other services and users affected. Mitigating an outage in a complex, globally distributed system is a Herculean task.

Using A State Page Aggregator to Monitor Cloud Outages​

IncidentHub is a cloud-based status page aggregator service that monitors the availability of your third-party cloud services. Outage detection is automatic and happens in real-time. In 2025 IncidentHub tracked more than 48000 outages across hundreds of SaaS and Cloud services.

Conclusion​

2025 saw a number of major cloud outages, especially in the infrastructure layer, demonstrating the impact that a few providers can have on other services and users.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

You might also like:

• H1 2026 Cloud and SaaS Reliability Report
• GitHub Outages 2025 - 2026: Reliability Analysis and Outage History
• The Definitive AWS Outage Report 2025: Reliability Analytics and Cascade Impact

Cloud outages like the recent ones at Cloudflare, Microsoft Azure, and AWS can have a significant impact on your business with downtime, lost revenue, and unhappy customers. They can also disrupt your team's ability to work effectively. To stay on top of such outages, your team needs to know about them in an easy and timely way.

In this article, we will see how to integrate IncidentHub cloud outage alerts with Microsoft Teams.

• The Impact of Cloud Outages on Your Business
• How Does IncidentHub Work?
• Configuring IncidentHub to Send Alerts to Microsoft Teams
  • Adding an integration for Microsoft Teams
    • Creating a Workflow in Microsoft Teams
    • Connecting IncidentHub With the Workflow
  • Fine-tuning Your Alerts
  • Understanding the Alerts
• Conclusion

How Does IncidentHub Work?​

IncidentHub is a cloud-based status page aggregator service that monitors the availability of your third-party cloud services by checking public status pages. It this by using a combination of API calls, webhooks, RSS feeds, and other methods.

Outage detection is automatic and happens in real-time. Users can choose to receive notifications for specific services in a tool of their choice which includes Email, Slack, Discord, Microsoft Teams, PagerDuty etc. It can easily integrate with Microsoft Teams to send alerts to your team's channel.

Configuring IncidentHub to Send Alerts to Microsoft Teams​

Once you have created an IncidentHub account you can choose the cloud services you want to monitor. This is covered in detail in the IncidentHub documentation. Next, we need to integrate IncidentHub with your Microsoft Teams channel so that it can send the notifications there.

Adding an integration for Microsoft Teams​

IncidentHub integrates with Microsoft Teams using Workflows. Let's do this step by step.

Creating a Workflow in Microsoft Teams​

→ Login to your Microsoft account and click on "Teams and channels" on the left sidebar in the Microsoft Teams app.

→ Click on the 3 dots (...) next to the channel you wish to receive notifications in.

→ Click on "Workflows" in the menu.

→ In the popup window, search for "webhook" and choose the template "Send webhook alerts to a channel".

→ Put a descriptive name for the workflow.

→ Confirm the Team and the Channel name.

→ Click on Add workflow.

→ Copy the HTTPS URL on the next screen. You will use it in the next steps.

Connecting IncidentHub With the Workflow​

→ Login to your IncidentHub account and click on Channels -> Add -> Microsoft Teams.

→ Add a Name and and a Description.

→ Under "Microsoft Teams Workflow URL", paste the URL that you had copied earlier.

→ To ensure the URL is valid and IncidentHub is able to connect to it, you can click on "Send a test message". This will send a test notification to your Microsoft Teams channel.

→ Click on "Save".

Fine-tuning Your Alerts​

To reduce alert noise, fine-tune them by choosing only relevant alerts. You can do this by:

1. Choosing specific components to monitor.
2. Choosing specific types of alerts to receive - outages, maintenances, or both. Services like Twilio, Cloudflare, and Salesforce have a ton of maintenance events and they can easily overwhelm your alert notifications.
3. Select the lifecycle events that you are interested in - beginning, end, or all updates.

These topics are explained in detail in the IncidentHub documentation.

Understanding the Alerts​

A Microsoft Teams notification sent by IncidentHub looks like this:

The alert is sent as an AdaptiveCard and summarizes all the important information about the outage/maintenance. The colored bar on the left indicates the type of event.

Conclusion​

IncidentHub's integration with Microsoft Teams is a powerful way to stay informed about cloud outages and maintenance events. It's easy to set up and can be customized to send only the relevant alerts to your team's channel. Try it out.

Photo by Hazel Z on Unsplash

IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders

This article was first published on the IncidentHub blog.

Over the last few months IncidentHub has added several new features to make it easier to fine tune your alerts. IncidentHub now also integrates with Microsoft Teams and supports custom domains for your public status pages. Let's take a comprehensive look at what's new.

• What's New In IncidentHub?
  • Fine-Tuning Alerts
  • Faster Component Filtering
  • Microsoft Teams Integration (Beta)
  • Detailed Historical Data Upto 90 Days
  • Custom Domains for Public Status Pages (Beta)
  • Test Buttons for Notification Channels
• Wrapping Up

Fine-Tuning Alerts​

You already could choose specific components when monitoring a service. Now on top of that, you can turn off specific types of event alerts for a service. For most services, IncidentHub can detect outages as well as maintenance events. Some services have a ton of maintenance events and they can easily overwhelm your alert notifications. You can turn off either maintenance alerts, or outage alerts, or both, or none. This setting is per-service.

The existing settings for lifecycle (start/end/updates) remain the same.

One of my worries while adding this feature was that it might make the user experience more complex.

Too many settings, which one should I choose?

However, this feature was more important than the lifecycle settings, so I had to add it. All settings in the Notifications tab have sane defaults. You can always change them later, depending on your needs, or you can leave them as-is.

Whatever you see in the Notifications tab is requested by customers with real use-cases. At the same time, I think it's also important to have a simple UI. I hope the current UI is a good balance between these two goals.

Faster Component Filtering​

Salesforce and Google Cloud Platform - to take two examples - each have thousands of components. This was a challenge to not just load on the UI but also for the user to choose by scrolling and selecting from the list.

The new UI has a search box where you can type and choose components. It's similar in behavior to the search box where you can search for services when you are adding a new monitored service. Behind the scenes, the difference is that it uses TanStack's react-virtual library.

Microsoft Teams Integration (Beta)​

IncidentHub now supports sending alerts to Microsoft Teams. This is a beta feature and is available for all paid plans on request. Since it's in beta, it's being rolled out in phases on an as-requested basis. Under the hood it uses Adaptive Cards which support JSON based templating to push rich notifications to Teams channels. The benefit of the templating model is that you can separate data from the layout, and thus change the layout independently of the notification content.

This is a screenshot from our production IncidentHub MS Teams channel which monitors IncidentHub's own dependencies:

Detailed Historical Data Upto 90 Days​

The previous version of the availability dashboard had just vertical bars indicating outage/non-outage days. The new page includes a list of the incidents that occurred in the last 90 days (30 days in free accounts).

The incidents and maintenance events that you will see in the list are automatically filtered by the components that you choose when adding the service. E.g. if you are monitoring GitHub webhooks only, and GitHub had outages in other components, you will not see any red days on the availability page. This behaviour mimics that of the main dashboard (where you can see a summary of incidents) and the public status page (where you can see a summary view as well as the list of components affected, plus the historical view as bars).

Custom Domains for Public Status Pages (Beta)​

Custom domains are finally here for public status pages.

This feature is in beta so there is no UI yet to configure it. You can request it by contacting support@incidenthub.cloud.

Test Buttons for Notification Channels​

Slack and Microsoft Teams both have a "Test" button that you can click to check if the channel is working. This is available before you add the channel and also after you have done so.

The buttons will send a test message to the channel to verify that it is working.

Wrapping Up​

What do you think? Let me know on X or Bluesky.

This article was first published on the IncidentHub blog.