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
• How IncidentHub Detected This
• 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

How IncidentHub Detected This​

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.

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. 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.

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.

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.

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.

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.

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.

This is an updated version of the 2024 article.

Maintaining transparent communication about service availability is crucial for businesses of all sizes. Status pages are an important part of your communication strategy during times of outages and maintenance events.

You can choose to go with a fully managed status page provider or host an open-source one yourself.

Open source status page software offer a cost-effective and customizable solution where you have complete control over the code, data, and presentation. This guide explores the best available open source status page software in 2025 to help you choose the right tool for your needs.

• Introduction
• List of Open Source Status Page Software
  • 1. Cachet
  • 2. Statping-ng
  • 3. Cstate
  • 4. Upptime
  • 5. Vigil
  • 6. Gatus
  • 7. StatusPal
  • 8. Uptime Kuma
  • 9. OneUptime
  • 10. Kener
  • 11. OpenStatus
  • 12. UptimeFlare
• Choosing the Right Open Source Status Page Software
• Summary
• Conclusion

List of Open Source Status Page Software​

1. Cachet​

Cachet is a popular open source status page system built with PHP and Laravel. It offers a clean, minimalist design and a robust feature set.

Key Features:

• Easy installation and setup.
• Metric graphs for visualizing performance.
• Maintenance scheduling.
• Multilingual support.
• Metrics.
• Service components.
• Two-factor authentication.
• JSON API for automation.
• Subscriber notifications via email.

Home Page: https://cachethq.io/
Source Code: https://github.com/cachethq/cachet
Demo Site: https://v3.cachethq.io/
Managed Version Available: No

Live page examples:

GNOME Status Page

EEA Status Page

2. Statping-ng​

Statping-ng is a Go-based status page that emphasizes simplicity and ease of use. It supports both SQLite and MySQL databases. Statping-ng is an updated replacement of statping after development stopped on the original fork.

Key Features:

• Lightweight and fast.
• Built-in monitoring capabilities for HTTP, TCP, UDP, gRPC, and ICMP.
• Customizable response checks.
• Customizable HTTP checks with headers and body.
• Mobile-friendly design.
• OAuth authentication fro GitHub, Google, and Slack.
• Native mobile apps for Android and iOS.
• Customizable themes.
• Prometheus exporter for advanced monitoring.
• Notifications on Slack, Email, and Twilio.
• Plugin framework.

Home Page: https://statping-ng.github.io/
Source Code: https://github.com/statping-ng/statping-ng
Demo Site: NA
Managed Version Available: No

Live page examples:

Jellyfin Status Page

Boniface Labs Status Page

3. Cstate​

Cstate is a Hugo-based static status page generator that emphasizes simplicity and performance.

Key Features:

• Fast page load times.
• Fully customizable through Hugo templates.
• Supports multiple content formats (YAML, JSON, TOML).
• Multilingual support.
• Automatic light/dark mode.
• Easy deployment to Netlify or GitHub Pages

Home Page: https://cstate.netlify.app
Source Code: https://github.com/cstate/cstate
Demo Site: https://cstate.mnts.lt
Managed Version Available: No

Live page examples:

Chocolatey Status Page

Testing Farm Status Page

4. Upptime​

Upptime is a GitHub-powered open source uptime monitor and status page generator.

Key Features:

• No server required - runs entirely on GitHub Actions.
• Scheduled maintenance support.
• Workflows integrate with GitHub - issue creation, summary, response graph generation, response time calculation, etc.
• Real-time notifications via GitHub Issues.
• Custom domain and SSL support through GitHub Pages.
• Graphs and badges for displaying uptime.
• Integrates with various monitoring services.
• Notifications via Slack, Telegram, Discord, Zulip, Microsoft Teams, Gotify, Email, SMS, and custom webhooks.

Home Page: https://upptime.js.org
Source Code: https://github.com/upptime/upptime
Demo Site: https://demo.upptime.js.org
Managed Version Available: No, but powered by GitHub Actions.

Live page examples:

Open Source Repos Status Page

Frai.se Status Page

5. Vigil​

Vigil is a lightweight status page written in Rust, designed for high performance and low resource usage.

Key Features:

• Simple configuration using TOML files.
• Built-in monitoring capabilities for HTTP/TCP/ICMP, application services, and local services (e.g. on a different network away from the main server).
• Support for push notifications.
• Planned maintenance notices.
• Integrates with Email, Twilio (SMS), Slack, Zulip, Telegram, Pushover, Gotify, XMPP, Matrix, Cisco Webex, and Webhooks.

Home Page: https://crates.io/crates/vigil-server
Source Code: https://github.com/valeriansaliou/vigil
Demo Site: NA
Managed Version Available: Crisp offers a managed version of Vigil ported to their own infrastructure.

Live page examples:

Crisp Status Page

Autoinspector Status Page

6. Gatus​

Gatus is a health dashboard and status page that monitors services and endpoints using HTTP, TCP, and other network protocols.

Key Features:

• Inbuilt health checks - HTTP, ICMP, TCP, DNS.
• Condition-based rule evaluation of health query results.
• Support for tunneling to monitor services on a different network.
• Customizable alerting - supports various providers like AWS SES, Discord, Email, Gitea, GitHub, GitLab, Google Chat, Gotify, HomeAssistant, IFTTT, Ilert, Incident.io, Line, Matrix, Mattermost, Messagebird, n8n, New Relic, Ntfy, Opsgenie, PagerDuty, Plivo, Pushover, Rocket.Chat, SendGrid, Signal, SIGNL4, Slack, Splunk, Squadcast, Teams, Teams Workflow, Telegram, Twilio, Vonage, Webex, Zapier, Zulip, etc.
• Customizable alert thresholds.
• Support for announcing planned maintenance.
• Basic auth and OIDC support.
• Metrics visualization.
• Easy to configure using YAML.
• Automatic badge generation for monitored endpoints.
• Docker support for easy deployment.

Home Page: https://gatus.io/
Source Code: https://github.com/TwiN/gatus
Demo Site: https://status.twin.sh/
Managed Version Available: Yes

Live page examples:

Skobk Status Page

Defense Unicorns Status Page

7. StatusPal​

StatusPal is an Elixir-based status page system. The repository has not been updated in a while as of this writing but they also offer a managed version.

Key Features:

• Email and Tweet notifications.
• Private and public status pages.
• Component support.
• API for integration with monitoring tools.
• Multi-language support.
• Scheduled maintenance announcements.

Home Page: https://statuspal.io/
Source Code: https://github.com/statuspal/statuspal
Demo Site: NA
Managed Version Available: Yes

Live page examples:

Unity Status Page

UCheck Status Page

8. Uptime Kuma​

Uptime Kuma is a monitoring tool with a built-in status page feature.

Key Features:

• Uptime monitoring for HTTP, TCP, DNS, Keywords, Ping, Steam Game Server, Docker Containers.
• Multi-language support.
• 2-factor authentication
• Docker support
• Notifications via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), etc
• 20-second intervals
• Multiple status pages
• 2FA support

Home Page: https://uptime.kuma.pet/
Source Code: https://github.com/louislam/uptime-kuma
Demo Site: https://uptime.kuma.pet/
Managed Version Available: No

Live page examples:

Sidings Media Status Page

BluDood Status Page

9. OneUptime​

An observability platform that also has status pages.

Key Features:

• Uptime monitoring.
• Customizable public status pages.
• Notifications via Email, SMS, Slack etc
• Custom branding on your status page.
• On-call policies, schedules and alerts.
• Log management.
• Incident management workflow.
• Application Performance Monitoring.

Home Page: https://oneuptime.com/
Source Code: https://github.com/OneUptime/oneuptime
Demo Site: NA
Managed Version Available: Yes

Live page examples:

Look & Play Status Page

Cloudiabot Status Page

10. Kener​

Monitoring and status page tool written in Node.js.

Key Features

• Monitoring support for HTTP, DNS, TCP, Ping, SQL, SSL, Heartbeats, Gamedig, etc.
• Quick setup with Docker.
• Dark/light mode support.
• Notification support on Discord, Slack, Email, and Webhooks.
• In-built support for SEO tools.
• Timezone auto-adjustment.
• Role based access control.
• Badge and embded support.
• API based incident creation.
• Customizable branding.
• i18n support.

Home Page: https://kener.ing/
Source Code: https://github.com/rajnandan1/kener
Demo Site: https://kener.ing/
Managed Version Available: No

Live page examples:

Nocodb Status Page

Rephealth Status Page

11. OpenStatus​

A performance monitoring platform written in Typescript and Go with public status pages.

Key Features

• API, DNS, Domain, SMTP, Ping etc monitoring - with latency, uptime, availability metrics.
• OpenTelemetry support for metrics.
• Password protection and custom domain support for status pages.
• Scheduled maintenance support.
• User notification support via Email, SMS, Discord, OpsGenie, PagerDuty, Slack, Ntfy, and Webhooks.

Home Page: https://openstatus.dev/
Source Code: https://github.com/openstatusHQ/openstatus
Demo Site: NA
Managed Version Available: Yes

Live page examples:

Birdeye Status Page

Documenso Status Page

12. UptimeFlare​

A serverless uptime monitoring tool with a built-in status page.

Key Features

• Serverless uptime monitoring.
• Geo-specific checks.
• HTTP/HTTPS/TCP port monitoring.
• Customizable request methods, body, and headers, and custom status codes and response checks for HTTP.
• Scheduled maintenance support.
• Built-in status page with customizable branding.
• Notifications via Email, SMS, Discord, OpsGenie, PagerDuty, Slack, Webhooks etc. using the Apprise library.
• Password protection for status pages.
• JSON API for status data.

Home Page: https://uptimeflare.pages.dev/
Source Code: https://github.com/lyc8503/UptimeFlare
Demo Site: https://uptimeflare.pages.dev/
Managed Version Available: No

Live page examples:

Sei AI Status Page

Dockrelix Status Page

Choosing the Right Open Source Status Page Software​

When selecting an open source status page software, consider the following factors:

1. Ease of installation and maintenance.
2. Compatibility with your existing tech stack.
3. Customization options and flexibility.
4. Community activity and long-term support.
5. Integration capabilities with your monitoring tools.
6. Performance and scalability.
7. Notification and alerting options.
8. Historical data retention and display.
9. User management and access control.

To elaborate on #5 - some of these status pages are part of a bigger monitoring toolkit where the status data is drawn from the same toolkit's monitors. If the status page does not support data from other sources you might not be able to use only the status page feature in such tools. Others are standalone status pages - where you can push incident events from anywhere you want. This is an important factor to keep in mind.

Summary​

Conclusion​

Open source status page software offer a cost-effective way to keep your users informed about your service's health and performance. By choosing the right tool from this guide, you can enhance transparency, build trust with your users, and streamline your incident communication process.

This article was first published on the IncidentHub blog.

The role of third-party SaaS and cloud services in the modern software development stack needs no explanation. Primarily due to the ease of setting and hooking them up together, they make the software development lifecycle (SDLC) much easier than it was 10 years ago. No more managing the overhead of installing, configuring, maintaining, backing up, and scaling of source code repos, virtual machines, and CI/CD systems. Some SaaS services don't have any in-house options, e.g. payment gateways, so you have to use them.

This dependency on third-party services also brings risks. The more such services in the chain, the more likely it is that a failure in one of them will impact or even cripple your smoothly running development and deployment pipeline. These failures by extension will also impact your business and customers.

You have vetted and chosen reliable services. However, outages happen. The best you can do is to prepare for them and know when they occur. This article is about the knowing part.

• Introduction
• The Role of Third-Party Services
• The Impact of Third-Party Outages
  • Who is Impacted?
• Monitoring Third-Party Service Outages
  • How Can I Monitor Third-Party Dependencies During an Incident?
  • Tracking Status Pages Manually
  • Tracking Status Pages with a Status Page Aggregator
• Best Practices
• Conclusion
• Summary

The Role of Third-Party Services​

A typical software development organization has many third-party services:

• Infrastructure
  • DNS
  • Cloud Provider
  • PaaS
  • Content Delivery Network
• Monitoring
  • Observability
  • On-call management
• Communication and Collaboration
  • Email
  • Chat
  • Office suites
• Development and Operations
  • Source Code Repositories
  • CI/CD
  • Artifact repositories
  • LLM APIs
  • Auth APIs
  • Artifact repositories
  • Project management
• Product-function related SaaS
  • Payment gateways
  • SMTP Providers
• Other product functions
  • Marketing
  • Customer support and ticketing
  • Analytics

It's not uncommon to have more than 100+ third-party services. According to the 2025 State of SaaS report, companies use an average of 106 SaaS apps. Knowing when a service is unavailable is important to many folks, including your development and operations teams. Your product reliability depends directly on external services.

The Impact of Third-Party Outages​

Recently, somebody asked me:

"So what if you know that a service is down? What is the point of knowing if you cannot do anything about it?"

Sounds logical.

However, the question assumes that it is easy to determine which service is experiencing an outage. So let me break that down:

• It's hard to know which of your hundreds of dependencies has an outage. The problem of checking different status pages, support forums, social media, and so on explodes when you have to do it for 10+ services. If you have just 1 or 2, it's easy to check.
• There is something you can do about it. Once you know that a particular service has an outage, you can save your team hours of debugging and troubleshooting. IncidentHub was born out of such personal experiences in my past roles where I doubled as a backend dev and Ops engineer. I could see the impact that a GitHub outage had on my dev team (PRs stuck, builds failing), and also the impact that a Slack outage had on my sales team (lost/delayed messages, anyone?). And nobody knew why. The status pages had the answers all along.

The real cost here is the waste of developer time and customer escalations.

Who is Impacted?​

Third-party services can directly impact you and your team.

• If you are a SaaS vendor, your product's reliability is dependent on the reliability of the third-party services it uses.
• If you provide mobile/web app development services, your ability to deliver on time depends on the availability of your third-party vendors.

Knowing which services are down - and when they are back up - is better than being in the dark about the fact that an external service has caused a problem.

Monitoring Third-Party Service Outages​

How Can I Monitor Third-Party Dependencies During an Incident?​

If you have third-party incident tracking as part of your incident management process, you have already taken the first step. The most common way to track third-party outages is to check their status pages. But how do you track hundreds of status pages?

Tracking Status Pages Manually​

Manual monitoring of status pages is fraught with challenges:

• Status page providers can change and break existing subscriptions and notifications without warning.
• Many status pages offer RSS feeds only without component/region filtering, forcing you to drown in alert noise.
• Manual monitoring of 100+ status pages is not practical.
• Some status pages lack feeds or subscription options.
• Status page URLs can change, leaving you unaware of outages.
• DIY solutions like pushing RSS feeds into Slack lack filtering capabilities, can break when status pages change, and are an ongoing maintenance burden on your teams.

Tracking Status Pages with a Status Page Aggregator​

A status page monitor/aggregator can simplify the process of tracking status pages.

A status page aggregator like IncidentHub:

• Offers a single normalized view across cloud providers' status pages.
• Hides the complexity of different status page formats.
• Detects and adjusts to changing status page formats over time.
• Let's you choose the notification mode you want for alerts.
• Offers notification modes not available on the status page.
• Let's you analyze historical data and availability trends.

When you use a status page aggregator, you can choose to receive only those alerts that are relevant. Depending on your team's needs, you can push the alerts to any of the following:

• A Slack channel.
• A Discord channel.
• A custom webhook that integrates with your internal dashboard.
• A team email address.
• A Microsoft Teams channel.
• A Zendesk workspace.
• A custom integration using APIs.

Another option if you choose not to receive alerts is to put up a unified status page on a large screen TV or monitor. It shows you the overall status of all your third-party dependencies at a glance.

Overall, a better developer experience.

Check out this short video tutorial on how to set up a unified status page with all your third-party services with a status page aggregator.

Best Practices​

If you are monitoring third-party services using a status page aggregator like IncidentHub, there are a few best practices you should follow:

• Fine-tune your alerts so that your team is not overwhelmed by alert fatigue.
• Check in with your team periodically to see if they are seeing value from the alerts. If not, a unified status page displayed prominently might be better suited for your team.
• Periodically ensure that the list of monitored services and components is up to date.
• Include third-party service outages in your incident response plan.

Conclusion​

Third-party services form a key part of your software development stack. Knowing when a service is down is important to many folks, including your development and operations teams. A status page aggregator like IncidentHub can help you track third-party outages and let's you focus on product development.

Summary​

You might also like:

• Top 6 Reasons Why You Need a Status Page Aggregator
• Product Update - Public Status Pages
• A Step by Step Guide to Checking if a SaaS is Down

This article was originally published on the IncidentHub blog.

All product names, company names, logos and trademarks are the property of their respective owners.

Photo credits: SEO Galaxy on Unsplash

Last updated on September 2, 2025.

Incident management tools play a key role in helping organizations to effectively handle service outages. With so many incident management tools around with different feature sets, it's often difficult to find the one that is right for your needs. In this article, we attempt to make a list of incident management software available in 2025 with their features to help you arrive at the right one.

We have focused on tools that have incident management capabilities. We have left out many good tools which are focused only on incident response, or on monitoring and alert triggering, or on ticket management to avoid cluttering this article.

There are a few additions and removals compared to the 2024 list.

• Introduction
• Benefits of Using an Incident Management Tool
• How To Choose the Right Incident Management Tool
  • Features
  • Cost
  • Support
  • Reliability
  • Integration With Your Workflow
  • Ability to Scale With Your Growth
  • Documentation
  • Ease of Use
  • Data Security
• Trends in Incident Management Tools in 2025
  • AI Ops
  • Focused Workflows
• List of Incident Management Tools in 2025
  • PagerDuty
  • ServiceNow
  • Splunk On-Call
  • Grafana Cloud IRM
  • iLert
  • incident.io
  • FireHydrant
  • Squadcast
  • Better Stack
  • Rootly
  • xMatters
  • AlertOps
• Conclusion

Download a summary of this article as a PDF

Benefits of Using an Incident Management Tool​

• An incident management tool streamlines the incident management process by defining and automating workflows for your on-call teams. It can assist you in creating runbooks, alerting policies, escalation policies, and defining and managing on-call schedules.
• Incident management software can integrate with your in-house observability stack. Your observability stack is a key source of incidents.
• Incident management tools can integrate with third-party observability and uptime monitoring tools, which are another source of incidents.
• They can also integrate with your existing communication and collaboration tools to provide real-time updates.
• Some incident management tools add context to your ongoing incidents by pulling in data from your infrastructure, applications, and observability systems. This can add significant information to narrow down the root cause.
• Incident management tools can provide analytics which can be used to gain insights into patterns and performance to create a culture of continuous improvement.
• An incident management tool can also generate audit trails and standardized documentation for compliance requirements.
• Incident Management software can also provide status pages - both internal and external - for your stakeholders.

How To Choose the Right Incident Management Tool​

The important thing to note here is that you need to choose the right tool, not necessarily the best one in the market, or what the majority is using. To do that you need to define the right criteria. These guidelines will help you to arrive at the parameters you can look at to evaluate tools.

Features​

Identify the key features you absolutely need to have. Shiny features that sound good to have and may be helpful for other teams need not necessarily be a part of your checklist. Work with your team to identify the features you need. Does the tool have them in a single pricing tier that fits your budget?

A non-exhaustive list that you can use to arrive at a decision:

• Incident lifecycle management
• On-call scheduling and management
• Schedule overrides
• Alerting policies
• Third-party integrations
• Analytics and reporting
• Status pages
• Role-based access control
• API access
• Runbooks integration
• Mobile app

Cost​

Cost is obviously an important factor. Does the tool have transparent pricing? Are there any hidden costs?

Support​

Does the tool have 24/7 support? How responsive is their support team? Look at the various channels by which you can reach support - phone, email, chat, social media channels.

Reliability​

Does the tool have a good track record of being available? How transparent are they about their uptime? Look at their public status page and search for reviews on social sites. What are other users saying about their experience?

Incident management tools need to be always available and reliable - or you run the risk of not knowing when anything goes wrong.

Integration With Your Workflow​

The tool should integrate well with your existing workflow. Your team probably already has a well-defined one. Look at the third-party integrations available. Some might integrate directly with your communication and collaboration tools, others might need custom API integration.

Ability to Scale With Your Growth​

Do a forecast of how much your team and infrastructure will grow in the next few years. Would that lead to an increase in your monthly bill for the tool from more users/alerts/etc?

Documentation​

Does the tool have comprehensive documentation? Can your team find easy-to-follow instructions on how to use it? What about advanced use cases?

Ease of Use​

A good UI is crucial, especially in times of crisis. The UI should be intuitive, and have an easy way to both summarize the ongoing incidents and drill down into the details.

Data Security​

Read the data security and privacy policy for the tool. Depending on your business's regulatory requirements, you might need to have a tool that is compliant with your required data security standards.

Trends in Incident Management Tools in 2025​

AI Ops​

AI-based incident management, alert grouping, automated root cause analysis, and natural language interaction for incidents are growing. Although a lot of tools have incorporated AI-based features, it's still in its infancy when it comes to automated remediation. Security risks are also a concern.

Focused Workflows​

More and more tools are focusing on the ability to handle the entire incident lifecycle in one place. For example, Slack-based incident management tools - for teams that use Slack - enable users to manage incidents directly from Slack. This makes it easier for users to collaborate during high-stress situations as they are working in a familiar environment with ready access to colleagues and other information.

List of Incident Management Tools in 2025​

PagerDuty​

Key Features

• Alerting over multiple channels including phone, app, email.
• On-call management - scheduling, roster management, overrides.
• Rule definitions for alert routing.
• Integrations with most common tools.
• APIs for incident lifecycle management.
• Status pages.
• Support for teams with role-based permissions.
• Integration with ITSM tools.
• Analytics.
• Single sign-on.
• Maintenance mode

PagerDuty is best for large enterprises requiring comprehensive incident management, although it can be used by smaller teams too.

ServiceNow​

Key Features

• On-call scheduling with overrides.
• Supports multiple notification channels.
• Automated ticket routing.
• SLA tracking.
• Compliance and governance features.
• Integrations with many third-party tools.
• Analytics.

It's best suited for organizations using ServiceNow products like ITSM.

Splunk On-Call​

Key Features

• On-call schedules and overrides.
• Role-based permissions.
• Rules engine for triggering custom actions.
• Incident waiting rooms to reduce alert fatigue.
• Maintenance mode
• Notifications via email, phone, SMS, email, app push.
• Third-party integrations with many common tools.

Splunk On-Call, formerly VictorOps, is best suited for teams already using Splunk for monitoring.

Grafana Cloud IRM​

Key Features

• Open source and also has a managed solution.
• Alert grouping.
• Escalation policies.
• Alert routing.
• Calendar-based on-call schedule and roster.
• Maintenance mode.
• Integrations with common third-party tools - Slack, SMS, Telegram, Phone.
• Role based access control.
• Analytics.

Formerly known as Grafana OnCall, the OnCall and Incident apps were merged into a single Grafana Cloud IRM. Grafana Cloud IRM works seamlessly with other Grafana Cloud products, so it is best suited for teams already using Grafana for monitoring.

iLert​

Key Features

• On-call schedules and escalation policies.
• Notifications using SMS, push, voice call.
• Maintenance support.
• Critical phone call routing using customizable multi-language IVR.
• Public status pages.
• Integrations with MS Teams and Slack for chatops-based incident management.
• Integrates with most common tools.

iLert is best suited for mid-sized Ops teams.

incident.io​

Key Features

• On-call scheduling and escalations, with overrides.
• Notifications with app push, phone, email, Slack, MS Teams.
• Incident lifecycle management from within Slack.
• Private incidents support.
• API for integration and data access.
• Status pages.
• Analytics.
• Third-party integrations.
• Integrates with CRM systems.

incident.io focuses on being an incident management platform with a Slack-first approach.

FireHydrant​

Key Features

• On-call management.
• Notifications on app push, Slack, Whatsapp.
• Runbooks.
• Service catalog.
• Incident retrospectives.
• Analytics.
• Integrates with most common tools.
• Status pages.

FireHydrant with its strong incident workflows and retrospectives is best suited for SRE teams.

Squadcast​

Key Features

• On-call scheduling, escalation policies, and overrides.
• Integrations with common tools.
• Live call routing to connect to on-call folks directly.
• Alert classification and routing rules.
• Auto-pause flapping alerts.
• Analytics.
• Manage incidents directly from Slack.
• Runbooks.
• Status pages.

Squadcast, acquired by SolarWinds, is meant for modern SRE and Ops teams with its alert routing, post-mortem support, and chatops features.

Better Stack​

Key Features

• On-call scheduling and escalation policies.
• Incident grouping.
• Status pages.
• Integrations with common tools.
• Single-sign on.
• Teams support.

Better Stack is a suite of products that includes monitoring and logging also, but we felt it should be included in this list because of its integrated on-call features.

Rootly​

Key Features

• On-call scheduling, escalation policies, and overrides.
• Alert grouping based on time-window and on content.
• Integrates with many third-party tools.
• Playbooks.
• Support for managing the incident lifecycle directly from Slack.
• Retrospectives with automatic data capture and sync with Jira.
• Analytics.

Rootly specializes in automating incident workflows with strong integration capabilities and customizable playbooks.

xMatters​

Key Features

• Alert threshold configuration.
• Automatic correlation between alerts that might relate to the same underlying issue.
• Ability to subscribe to notifications as an observer.
• Integrates with many common tools like Slaack, ServiceNow, Google Chat, MS Teams, etc for alerting
• Supports cloud provider integrations for monitoring with AWS, Azure, GCP, etc.
• Detailed analytics and reporting.
• Incident timeline view.
• On-call scheduling, rotation, and management.
• SMS, Phone, Push notifications.
• Status pages.
• Mobile apps for iOS and Android.

xMatters is suited for Ops/SRE and IT Teams and also for teams that have special regulatory requirements like healthcare and financial services.

AlertOps​

Key Features

• On-call scheduling, rotation, and management.
• Dynamic alert routing and grouping.
• Custom data enrichment to add more context to alerts.
• API-based integration with.
• Integration with Slack, MS Teams, etc.
• Integrates with Ops/SRE tools like Jenkins, GitLab, GitHub, Prometheus.
• Predefined message templates.
• Status pages.
• Post-mortem reports.
• AI-based grouping and natural language interaction for incidents.

AlertOps is used by IT operations, Ops, and incident response teams to manage alerts and coordinate response.

Conclusion​

Choosing an incident management tool involves looking at the problem holistically:

Choose the tool that is right for you and your team.

You might also like:

• The No-Nonsense Guide to Runbook Best Practices
• The Rising Role of Slack in Incident Management
• Best Practices for Planning for Upcoming Cloud Maintenance
• A Step by Step Guide to Checking if a SaaS is Down

This article was originally published on the IncidentHub blog.

All product names, company names, logos and trademarks are the property of their respective owners.

Photo credits: Jonathan Gallegos on Unsplash

Last updated on August 8, 2025.

A public status page forms the public face of your organization's service availability. It is the first point of contact for your customers to check the status of your services during times of crisis. Hence, ensuring the credibility and uptime of your public status page is crucial to your organization's reputation.

In this article we will look at the key mistakes to avoid while hosting and managing a public status page.

• Introduction
• Public Status Page - Expectations
• Uptime Mistakes to Avoid
  • Hosting the Status Page on the Same Infrastructure
  • Sharing a DNS Provider With Your Primary Domain
• Provider Mistakes to Avoid
  • Choosing a Managed Provider Without an SLA and Support
  • Choosing a Provider That Does Not Have an API
• Credibility Mistakes to Avoid
  • Not Acknowledging Outages
  • Not Owning Up to Mistakes
  • Omitting Status Page Updates from Your Incident Management Strategy
• Transparency Mistakes to Avoid
  • Not Publishing Meaningful Post-Mortems
• Communication Mistakes to Avoid
  • Being Vague About the Ongoing Status
  • Stating Vague Timelines
  • Not Having an Easy Way To Reach Your Support Team
• Actionability Mistakes to Avoid
  • Not Including Workarounds
• Discoverability Mistakes to Avoid
  • Leaving Out the Link to Your Status Page From Your Website
  • Not Linking the Status Page From Your Social Media Channels
• Usability Mistakes to Avoid
  • Not Paying Attention to the Design
  • Not Paying Attention to Accessibility
• Conclusion
• Summary Table

Public Status Page - Expectations​

What do your customers and users expect from a public status page?

The important things are:

1. Uptime. The status page should be up and running at all times.
2. Reliability. The status page should be hosted by a reliable provider if you are using a managed provider.
3. Credibility. The status page updates should be managed by your team and reflect the actual status of your services and have a history of being open about incidents and maintenance.
4. Transparency. The status page should be honest about the actual status of any ongoing incident or maintenance.
5. Communication. The status page should be updated with clear and concise information in a timely manner.
6. Actionability. The status page should provide guides and workarounds, if any, for customers.
7. Discoverability. Last but not least, users should be able to find the status page easily, either from your website home page, from your support portal, or from your social media channels.
8. Usability. The status page should be easy to use and navigate.

To meet these expectations, you have to ensure that the status page's importance is appreciated across your organization.

Uptime Mistakes to Avoid​

Hosting the Status Page on the Same Infrastructure​

Think about it - if the same Google Cloud zone that hosts your primary application hosts your status page, and that zone goes down, your status page will be down along with your applications. You would have no way to update the status page. Cloud providers have zonal and regional isolation to limit the impact of outages. If you are hosting your status page yourself, use this fact and deploy your status page in a different zone or region.

However, if you are using a managed provider, this is usually out of your control. At best, you can check with the provider if they host their infrastructure in the same cloud provider as yours or in a different zone or region. If you are using a managed provider, they will usually ensure that they have high availability for their customers' status pages.

Screenshot from Heroku's June 10 outage summary.

Screenshot from Google Cloud post-mortem.

Sharing a DNS Provider With Your Primary Domain​

Your status page would probably be hosted on something like status.yourdomain.com where yourdomain.com is your primary domain. This leaves your status page vulnerable to outages in your DNS provider.

Strategies to follow here in order of increasing risk:

1. Use a different registrar for your status page domain. This naturally implies a different domain. You also have to ensure that you choose a different DNS provider as well. You can configure your DNS provider's root servers in your registrar settings. Why a different registrar? See the Zoom outage example below.
2. Use a different domain with the same registrar but a different DNS provider.
3. (Not recommended) Host your status page on a subdomain of your primary domain.

Provider Mistakes to Avoid​

Choosing a Managed Provider Without an SLA and Support​

A status page provider is just like any other service provider like your cloud vendor or payment gateway. Before you choose a provider, make sure they have an acceptable SLA. Look at online reviews and past outage reports to get an idea of their reliability.

The ability to reach their support team easily is also important. If the provider has multiple support channels, make sure they are reachable. Add their support contacts to your incident response playbook.

Choosing a Provider That Does Not Have an API​

Your uptime monitoring systems will integrate with your status page provider to automatically update the status page about availability trends. If the provider does not have an API, you will have to manually update it. It can quickly become a bottleneck. Manually updating the status page for uptime information is not a good use of your time.

However, during incidents, you will want to post manual updates, as they are based on the results of human investigation. A provider that has APIs as well as a way to manually post incidents is a good choice.

Credibility Mistakes to Avoid​

Not Acknowledging Outages​

When you become aware of an outage, the first step is to acknowledge it. The outage could be detected either by your own monitoring systems or in the worst case, by your customers. Update the status page to reflect the situation. At the outset, your team might not have all the information, which is fine. Accept the fact and post periodic progress updates as you get more information.

Not Owning Up to Mistakes​

Once you have mitigated the outage and systems are up and running, your team will prepare a post-mortem report. The outage could have been caused by an outage in your cloud vendor, or a bug in your code, or other dependencies, or a human error. Accepting mistakes and addressing them publicly is a good way to build credibility and trust.

For an example of a detailed post-mortem, see Google Cloud Networking Incident #19009.

Omitting Status Page Updates from Your Incident Management Strategy​

Your incident management strategy should include updating your status page. During an incident, your team will be busy investigating the incident and internal communications. It is easy to forget that your customers, and not just the ones reaching out to your support directly, need to be informed. Adopting status page updates as part of your process will ensure that it is done.

Transparency Mistakes to Avoid​

Not Publishing Meaningful Post-Mortems​

A post-mortem is a detailed analysis of an incident. It lays out the root causes, lessons learned, and recommendations for improvement. Your internal post-mortem report will have a lot of internal information that you might not be able to share. However, it is absolutely necessary to publish a public post-mortem which includes as much detail as possible without revealing sensitive information.

You can post the post-mortem on your status page as a follow-up to the incident. You can also publish it on your blog or social media channels.

Communication Mistakes to Avoid​

Being Vague About the Ongoing Status​

• "There is an incident and we are looking into it." (We know that already. When will you update us next?)
• "Some of our customers are experiencing issues." (Which systems are affected so that I can check if I am affected too?)

These do not convey much useful information to your customers.

Initially, your team might not be aware of which systems are affected and the impact of the outage. This is totally fine. As your investigation progresses, you can update the status page with more information. The first update you post will not have much concrete information, but you can still say that you will post the next update within a specific period of time.

Stating Vague Timelines​

Not so good updates:

• "We are working on it."
• "We will update you as soon as possible."

A better update:

• "We are working on it and we will post the next update in 30 minutes."

After 30 minutes, even if you have not made much progress, post an update. Your customers will appreciate the fact that you are not just working to fix the issue but are also communicating with them.

Screenshot from an incident update.

Not Having an Easy Way To Reach Your Support Team​

Your support team might be on one or more of these:

• Helpdesk software
• Email
• Chat
• Social Media
• Phone

Link to your support team from your status page, and make sure your support portal is separately hosted or managed by an external provider.

Actionability Mistakes to Avoid​

Not Including Workarounds​

If your customers are affected by the outage, share any known workarounds or alternatives, if any.

Screenshot from a workaround from Hetzner's status page.

Discoverability Mistakes to Avoid​

Leaving Out the Link to Your Status Page From Your Website​

Link to your status page from your website and your support portal. Most services will have a link to their status page on their website footer.

Not Linking the Status Page From Your Social Media Channels​

Link to your status page from your social media channels. When there is an outage, people might visit your social media outlets like X looking for updates about it. Making it easy to find your status page will also decrease the load on your support team.

Usability Mistakes to Avoid​

Not Paying Attention to the Design​

Your status page need not be a work of art fit to be hung in a museum, but it should be easy to use, navigate, and read. Users are going to visit your status page repeatedly, so making it easy to use is important. Invest in a good, pleasant design, with the most important information at the top. A status page needs to communicate the overall status first, and then let users dig deeper into the details.

Many teams display their status pages in large screens in their offices and NOC (Network Operations Center) rooms. Give users the option to choose between a light and dark theme.

Not Paying Attention to Accessibility​

Accessibility is important for all users, but it is especially important for users with disabilities. Pay attention to the color contrast, font size, and other accessibility features. Use an online accessibility checker to ensure your status page is compliant with standards.

Conclusion​

A public status page is a crucial part of your organization's public presence. Ensuring it is up and running and that it is managed well is important to your organization's reputation. An updated and reliable status page is one of the key ways to build trust with your users and customers.

Summary Table​

Here's a comprehensive table of positive recommendations organized by category to help you create an effective public status page:

IncidentHub is not affiliated with any of the services and vendors mentioned in this article.

This article first appeared on the IncidentHub blog.

Cloud maintenance is a common practice in the tech industry. Whether you manage your own infrastructure or use a cloud provider, you will need to plan for maintenance and include it as part of your operational readiness. This ensures that your team is prepared for potential downtime and can deal with any incidents in a timely manner. This article will cover some best practices for planning for upcoming cloud maintenance.

• Introduction
• Types of Maintenance
  • Scheduled Maintenance
  • Emergency Maintenance
• Maintenance Planning
  • Impact Assessment
  • Operational Readiness
• During the Maintenance Window
  • Communication
  • Dealing With Unexpected Issues
• Tracking Upcoming Maintenance
  • Maintenance Notifications
    • Email Alerts
    • Dashboard Push Notifications
    • Use a Status Page Monitor/Aggregator like IncidentHub
• Conclusion

Types of Maintenance​

Based on advance preparedness, there are two types of maintenance - scheduled and emergency. It is important to understand that a maintenance need not always cause downtime. However, being prepared for downtime is one of the key aspects of maintenance planning.

Scheduled Maintenance​

A scheduled maintenance is a planned maintenance that is announced in advance, sometimes days or weeks or even months ahead. Scheduled maintenance announcements give sufficient opportunity to plan for any downtime.

Scheduled maintenances can be modified or cancelled. Some cloud providers give you a way to reschedule or control the maintenance window if it affects only your resources (and not other customers'). You can leverage this to your advantage to minimize the impact of the maintenance.

Some examples:

1. Amazon Web Services EC2 - AWS EC2 maintenance events involve starting and stopping the instances. You can schedule the maintenance during off-peak hours to minimize the impact. You can also trigger the start/stop yourself at a chosen time before the scheduled window.

2. Render - Render's scheduled maintenance can be rescheduled to a different time, and you can also choose to trigger it at a time of your choosing.

Emergency Maintenance​

An emergency maintenance is not planned and is triggered as a way to mitigate a critical issue. Users will still be notified but they may not have enough time to plan for it.

Maintenance Planning​

Planning for maintenance events in advance is an important part of your incident management strategy. The advantage your team has for maintenance events as opposed to incidents is that you can plan for them beforehand, and assess and mitigate any possible impact.

Impact Assessment​

A maintenance announcement will have at least these details:

• The expected start and end time of the maintenance - the "maintenance window".
• The cloud services affected.

Based on the services affected, your team can determine if there will be any impact on your own applications or users.

Operational Readiness​

If there will be impact to your own applications or users, you can plan for it by:

• Identifying the applications and services that will be affected. If it's a cloud service that your applications or services depend on, inform the affected teams so that they have workarounds in place. These can be measures like keeping standby servers in a different region as a fallback, or actively routing client traffic to a different region in your load balancer.
• Identifying the impact on your users. If it's a SaaS service like a communication suite, or an office productivity suite, informing your users in an org-wide channel lets them plan their work. They can ensure that no critical work is scheduled during the maintenance window.

During the Maintenance Window​

During an ongoing maintenance, these are the important things to keep in mind:

Communication​

Keep your team informed about the status of the maintenance. This can be done using your existing communication tools like Slack or MS Teams. Another option is to use a status page that is accessible to everyone in your organization and provides real-time updates.

Dealing With Unexpected Issues​

You can run into unexpected pitfalls due to various reasons:

• The maintenance window was longer than expected In such cases, the affected cloud resources may be affected for a longer period of time. For your own applications, the teams have to continue with their original mitigation plan and adjust as needed. For SaaS applications, inform your users as soon as possible so that they can plan too.
• The maintenance activity affected resources other than the ones that were announced This is rare but possible. In such cases track the cloud provider's status page and get in touch with their support. If you have a support contract with them, get in touch with your support representative.
• Your team missed planning for one or more of the applications or services that will be affected You have to treat this like any other incident and put your incident response plan into action. It's also an opportunity to improve your incident management process.

Tracking Upcoming Maintenance​

All cloud and SaaS services announce maintenance beforehand. You can track these announcements easily by using a status page monitor/aggregator like IncidentHub.

Maintenance Notifications​

Email Alerts​

You can receive email notifications by signing up on the cloud or SaaS provider's status page. However, this is cumbersome if there are too many status pages. Not all status pages offer this feature. It's also difficult to inform users in real time with this approach.

Dashboard Push Notifications​

Some cloud providers show you notifications on their dashboard. However, you need to be logged in and keep the browser tab open to see them. It's also not easy to track all your services easily, or communicate such updates to your team.

Use a Status Page Monitor/Aggregator like IncidentHub​

IncidentHub tracks and shows you a maintenance feed of all upcoming and scheduled maintenances across your services.

You can also set advance reminders and customize when you wish to receive them.

Sign up for an IncidentHub account to track your cloud and SaaS service maintenances in one place

Conclusion​

Maintenance tracking is an important part of your incident management process. It helps you stay informed about the status of your services and plan for any potential downtime, and lets your users plan their work in a better way.

Photo Credits: Ivan N on Unsplash

IncidentHub is not affiliated with any of the services and vendors mentioned in this article.

A public status page is a page that you can share with your team to show a summary view of your third-party dependencies. We rolled out this feature recently to all IncidentHub users. This article is a quick tour of the feature and how to set it up.

• Introduction
• The Value of a Public Status Page
• Setting Up a Public Status Page
• What's Next?
• Conclusion

The Value of a Public Status Page​

A public status page can be used to share your third-party service status with your team members or with your organization as a whole. During outages this page should be the first stop to check the status of your external services. For deeper analysis there is always the IncidentHub dashboard.

Setting Up a Public Status Page​

When you create an IncidentHub account, you get a public status page for free. You can customize the page with your logo and other branding options. Login to your account and click on the "Status Page" button on the navigation bar on the left.

On the configuration page, you can fill in the details of your status page like title, name of your company, URL, support email, and logo.

IncidentHub automatically creates a dedicated subdomain for your status page. You can copy the URL to this from the bottom of the configuration page.

A customized status page will look like this:

What's Next?​

We are working on making the public status page more useful with options for whitelabeling. Here's a sneak peek of what's coming:

• Theme customization
• Custom domains
• Password protection
• Subscription options
• Affected components view

Have a feature request? Let us know.

Watch our video tutorial on how to set up a public status page

Conclusion​

IncidentHub's public status page is a great way to keep your team informed about the status of your external services. Use it to improve your incident response.

You can sign up for a free (forever) account at IncidentHub.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article.

IncidentHub can send outage alerts to many external systems. You can choose from Slack, Webhook, Email, Discord, PagerDuty, and more. Alerts are effective only when they are relevant and actionable. In this article, we will explore how to fine-tune your IncidentHub alerts to receive only the relevant ones for your third-party services.

• Introduction
• What Are Relevant and Actionable Alerts?
• Fine-Tuning Your IncidentHub Alerts
  • Component Filtering
  • Component Auto-Detection
  • Alert Notifications – Beginning, End, or Everything?
• Best Practices
• Conclusion
• References
• FAQ

What Are Relevant and Actionable Alerts?​

For third-party services, an alert is relevant if it directly affects your business in some way. The third-party could be a cloud service, a SaaS application, or a payment gateway. An actionable alert is one that you can do something about. To keep your alerts relevant and actionable, you can use this checklist:

• Your applications/business should directly use the service or product that the alert originates from. For example, if you use Google Kubernetes Engine (GKE) in the us-central1 region, an alert from GKE in the us-central1 region is relevant. Alerts from GKE in other regions, or from other Google Cloud products, are not relevant.
• Some third-party services are more critical than others for your business. You would want to closely follow every outage update until it is resolved in a business-critical service. For not so critical services, it is okay to receive alerts only when the outage start and ends.

Irrelevant alerts just add to your already crowded list of notifications and cause alert fatigue. Let's see how to use IncidentHub's fine-tuning features to keep your alerts relevant.

Fine-Tuning Your IncidentHub Alerts​

Component Filtering​

Global services like Google Cloud and Microsoft Azure have many constituent services or components, and they are spread across different regions and zones. Your business most likely uses only a subset of these components. Here is how to filter alerts from the components you are interested in.

When adding a new service, you can select "Monitor Specific Components" and choose the ones you need. Some components might have sub-components.

In the example above, if you choose "App Platform" -> Amsterdam, London, and New York, you will receive alerts only when there is an outage in Amsterdam, London, or New York for App Platform.

You can add change the monitored components for a service at any time by clicking on "Edit" next to the service.

Component Auto-Detection​

Some services have a large number of components. Choosing the components manually is a chore, and there is also the risk of missing something that you forgot about. To mitigate this, IncidentHub can auto-detect the components for you using the invoice for your cloud provider uploaded as a CSV file.

We don't store your billing data. It is only used during the auto-detection process. You can also remove the financial information from the CSV file before uploading it - IncidentHub needs only the service names.

As of this writing, this feature is in beta and available for Google Cloud Platform only. We are rolling it out to other services soon.

Alert Notifications – Beginning, End, or Everything?​

An outage goes through multiple stages - beginning, in progress, and resolved. The middle stage has one or more, sometimes many, updates - sent out by the service provider's team as they investigate and mitigate the issue. Depending on how critical the service is for your business, you might want to be notified only when the outage starts, or when it ends, or for everything.

You can fine tune this behavior for each monitored service.

This setting is per-service, and the default is to notify for everything.

Let me give you an example from IncidentHub itself. We use Paddle for our subscription billing. It's business-critical for us. We want to be notified for every update from Paddle outages and maintenance events. This helps us to be on top of issues and respond to customer queries quickly.

In contrast, we use Grafana Cloud as an external store for our logs. It is not business-critical and we are okay to miss the intermediate notifications as long we know an outage is ongoing or has been resolved. A Grafana Cloud outage does make it difficult to debug production issues, but we can temporarily fallback to our cloud hosting provider's log viewer.

Best Practices​

To get the most out of IncidentHub's alerting, you can follow these recommendations:

• Revisit your components for your services periodically to ensure they are up to date. Add or remove component filters as needed.
• Check your alert notification configuration once in a while - this might change depending on your business needs.
• If you or your team find yourself ignoring certain alerts, it's a sign that it's too noisy, and you need to reconfigure them.

Conclusion​

IncidentHub's alert fine-tuning features are designed to make alerts more meaningful and prevent alert fatigue. Use them to focus on what matters to your business.

You can sign up for a free (forever) account at incidentHub.cloud.

References​

• Component Filtering documentation
• Component Auto-Detection documentation
• Alert Notifications documentation
• More about component filtering

FAQ​

IncidentHub is not affiliated with any of the services and vendors mentioned in this article.

Last updated on August 8, 2025.

Your business depends on the reliability of the third-party services you use. Monitoring multiple status pages, one for each of these services, is the best way of keeping track of their outages and maintenances. Although some status pages let you subscribe to alerts, there is no standard way of doing this. Service providers can change their status page providers, disable subscriptions, or not support the same notification options.

A status page aggregator is a tool that solves all these problems by summarizing the status pages of multiple services in one place. If you depend on only 2-3 third-party services, you can probably get away without a status page aggregator. Beyond that, it becomes hard to stay on top of third-party service outages and maintenances, and leaves serious gaps in your monitoring.

Let's look at the top 6 reasons why you need a status page aggregator.

• Introduction
• Top 6 Reasons Why You Need a Status Page Aggregator
  • Services Can Change Status Page Providers
  • Not All Status Pages Let You Subscribe to Specific Components and Regions
  • There Can Be Too Many Status Pages To Track
  • Status Page URLs Can Change
  • Some Status Pages Don't Have Any Way of Subscribing to Outages
  • Home-Grown Status Aggregation Approaches Do Not Work
    • Stringing Up RSS Feeds Into Slack/Discord
    • Building Your Own Tool
• Conclusion
• Summary - Why You Need a Status Page Aggregator
• FAQ

Download a summary of this article as a PDF

Top 6 Reasons Why You Need a Status Page Aggregator​

Services Can Change Status Page Providers​

Businesses use a status page provider to create a managed status page that they can use to communicate with their customers and users. Depending on business needs, provider reliability, integration options, and more, businesses can change their status page provider. The status page URL would remain the same but the format and subscription options would change.

A recent example of such a move is OpenAI's status page. In Jan 2025, OpenAI was using Atlassian Statuspage. You can check it at the Wayback Machine.

The current OpenAI status page as of this writing is managed by Incident.io. The URL remains the same.

The subscription options have changed. If you were previously subscribed using webhooks, that option is no longer available. What's more, you would not even know that this happened. Once you setup the webhook subscription, you would not visit the status page except to check for details of outages and maintenances. If the subscription were removed, you would be blissfully unaware of any future outages. That is, until the outages start affecting your applications, and by extension, your business. You can end up with angry customers, lost revenue, and stressed SRE/Ops teams.

IncidentHub - a status page aggregator - automatically detects such changes. Using an aggregator shifts the responsibility of outage notifications to the aggregator, which can smooth over any differences in the status page providers.

Not All Status Pages Let You Subscribe to Specific Components and Regions​

Your third-party cloud and SaaS dependencies would be globally distributed and have many regions of operation. Your applications use a subset of these services. Why receive alerts for everything?

Some status pages, like Stability.ai's, let you subscribe to specific components and regions.

Others, like LiteLLM's status page, have an RSS feed only. If you connect the feed to your Slack channel using the /feed command, you will get notified of each and every outage in LiteLLM. There is no way to subscribe to a specific LiteLLM service from its status page.

A status page aggregator like IncidentHub lets you monitor specific components and regions as long as the information is on the status page. This is true even when the originating status page does not offer component-specific subscriptions.

There Can Be Too Many Status Pages To Track​

According to the State of SaaSOps Report 2024, organizations use an average of 112 SaaS tools. Even for smaller organizations and startups, most operations are outsourced to SaaS and Cloud vendors. 100+ tools means 100+ chances of unnoticed disruptions.

Monitoring all these services manually by tracking their status pages is not only hard but also not scalable.

Status Page URLs Can Change​

For various reasons, the third-party vendor's organization can change their status page URLs.

Cloudflare acquired Area 1 Security, which previously had its own status page. A few months ago, they removed the status page and Area 1's products are part of the Cloudflare status page now.

If you were previously monitoring Area 1's status page directly using just RSS feeds or email notifications, you might not have known about this change, leaving you exposed to undetected outages.

Another example is Railway's status page which moved from status.railway.app to status.railway.com.

IncidentHub detects such changes and auto-adjusts its monitoring.

Some Status Pages Don't Have Any Way of Subscribing to Outages​

Most status pages have at least an RSS or Atom feed. However, some status pages don't have any visible means of subscribing to outages. You need to keep refreshing the status page. This is just not feasible if you have a lot of dependencies.

Home-Grown Status Aggregation Approaches Do Not Work​

Stringing Up RSS Feeds Into Slack/Discord​

Using a glue script to string up RSS feeds into Slack/Discord is a common approach. While some status pages offer RSS feeds, not all of them do. Some status pages don't have any visible means of subscribing to outages. This approach also lacks any filtering capabilities for components and regions. You cannot search through historical data easily or look at ongoing incidents and maintenance at a glance. There is no single view of all your services. Additionally, some RSS feeds won't notify you when an incident is resolved. As noted above, this will break easily when anything changes in the status page provider or URL.

Building Your Own Tool​

Some engineering and IT teams choose to build their own tooling to get around the above problems. After all, why pay for a status page aggregator when you can build your own? Any self-respecting Ops Engineer/SRE would probably want to whip up a script and try to write this tool by themselves. However, such a homegrown solution requires a lot of upfront development and ongoing maintenance effort. The technical challenges themselves are significant. In addition, there are other costs:

1. Any software you write needs maintenance. E.g. when your organization starts using a new service that cannot be monitored using your existing tooling, you need to add support for it.
2. Somebody has to ensure reliability and uptime of the homegrown solution.
3. It becomes an additional burden on your already overburdened SRE/Ops teams.

Conclusion​

The challenges in monitoring multiple status pages yourself or using home-grown solutions are real. A status page aggregator like IncidentHub solves these problems by providing a reliable and scalable solution. IncidentHub adapts to status page quirks, URL changes, and more, continuously, where more basic tools can falter.

Summary - Why You Need a Status Page Aggregator​

Here's a tabular summary of the top 6 reasons why you need a status page aggregator:

Create an IncidentHub account to never miss an outage again.

FAQ​

This article first appeared on the IncidentHub blog.

IncidentHub is not affiliated with any of the services and vendors mentioned in this article.