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

IncidentHub has many integrations to receive alerts. You can choose from Slack, Webhook, Email, Discord, PagerDuty, and more. In this article, we will explore how to receive IncidentHub alerts in your webhooks.

• Introduction
• What are Webhooks?
• Using Webhooks For IncidentHub Alerts
  • Integrating Your Webhook
  • Testing your Webhook
  • The Webhook payload format
  • Webhook Security
  • Webhook Errors
• Best Practices
• Conclusion
• FAQ

What are Webhooks?​

Webhooks are a mechanism to receive notifications over HTTP whenever specific events occur. A common use case is to receive notifications from a third-party when certain events are triggered. Webhooks are an example of a push mechanism, as opposed to a pull mechanism like polling. The benefit of a webhook over a polling mechanism is that you only need to register your webhook URL once.

Using Webhooks For IncidentHub Alerts​

IncidentHub has a way to integrate with your webhooks such that you can receive all the usual notifications for incidents, including trigger, update, and resolve events.

Integrating Your Webhook​

Integrating your webhook is simple:

• Login to your IncidentHub account.
• Under "My Channels", click on "Add" and then select "Webhook".
• Enter a name and a description for your webhook.
• Enter the webhook URL.
• Click on "Save".

Webhooks are available in IncidentHub's Starter Plan and above. You can sign up directly for a Starter Plan from the website. If you are already a user on the Free plan, you can upgrade from your IncidentHub account dashboard.

Testing your Webhook​

While creating the webhook, you can test if IncidentHub can reach your URL. Enter your webhook URL in the popup and click on "Send a test message". IncidentHub will send a test payload to your webhook URL. If the test is successful, you will see a message "Success" - otherwise you will see an error message. You should also check your webhook server to verify that it received the payload correctly.

The Webhook payload format​

IncidentHub sends the payload to the webhook as a JSON in a POST request. The format looks like this:

"type": "updated" | "resolved",
"timestamp": time as a string with time zone indicator,
"data": {
    "service": Service name,
    "statusPage": Link to the official status page,
    "eventURL": Link to the incident,
    "content": Content of the incident,
    "title": Title of the incident,
}

An example payload looks like this:

{
    "type": "updated",
    "timestamp": "2024-10-01T22:38:01.725-07:00",
    "data": {
        "service": "Twilio",
        "statusPage": "https://status.twilio.com/",
        "eventURL": "https://stspg.io/mjg3188vltfh",
        "content": "We are experiencing call dialling delays to InUsually, ydosat Ooredoo Indonesia phone numbers. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 1 hour or as soon as more information becomes available.",
        "title": "Call Dialling Delays To Indosat Ooredoo Indonesia  Phone Numbers"
    }
}

The Content-Type: application/json header will be set on the request.

Webhook Security​

Your webhook must be a secure endpoint as it will called over the public internet. HTTPS is a must. Usually, you will add a secret token to the webhook URL. For example,

https://your-webhook-server.com/webhook/your-secret-token

IncidentHub will directly invoke your webhook URL with the payload. The webhook URL is stored encrypted in our database and is never exposed anywhere, not even to you in the IncidentHub dashboard. You cannot edit your webhook URL once it is created. To make any changes, delete the existing webhook and create a new one.

Webhook Errors​

If IncidentHub encounters an error while invoking your webhook, it will send an alert email to the email address that your account is registered with. This is a quick way of notifying you that there was an error. Until you fix the webhook, IncidentHub won't be able to send any notifications to it. Once it is fixed IncidentHub will automatically resume sending notifications.

A sample alert email looks like this:

You should have your own monitoring in place to periodically check your webhook. The IncidentHub webhook failure alert complements your monitoring and is not a substitute.

Best Practices​

• Do not share your webhook URL or store it in a publicly accessible place. This includes internal wikis and shared documents in your organization.
• Monitor your email for any alerts from IncidentHub with the subject "Your webhook had errors".

Conclusion​

Webhooks are a powerful way to receive IncidentHub alerts. They offer flexibility in integrating with almost any custom tool or system that you want. You can integrate these alerts with your internal monitoring systems, your Internal Developer Portal, or your status dashboard.

You can sign up for a free (forever) IncidentHub account and try it out.

FAQ​

You might also be interested in Integrate Incident Alerts With Discord Using Webhooks

For the last two months, we have focused on improving the onboarding experience for users so that they can get started with monitoring with minimal effort. We have also added several improvements in the backend to make the service more robust and reliable. Some of the usability improvements are driven by user feedback. Others incorporate what we would personally like to see in such a monitoring service. We have also improved the dashboard user experience.

• Introduction
• Easier onboarding
  • Service Component Autodetection
  • Commonly Used Services
  • Test Channels
• Dashboard Improvements
  • Services With Incidents
• Reliability Improvements
  • Alert Emails for Webhook Failures
  • Bug Fixes and Robustness Improvements

Easier onboarding​

Service Component Autodetection​

Setting up monitoring in IncidentHub is straightforward. However, choosing the right components for your services can be daunting, especially for ones that have hundreds of components like Google Cloud Platform and Amazon Web Services. If you miss out selecting a component, you will not receive alerts for it. On the other hand, if you select all components, you will be overwhelmed with irrelevant alerts.

Instead of you having to painstakingly choose individual components, we have added an autodetection feature. Just upload your billing report as a CSV file and we will automatically detect your components for you.

This feature is available for Google Cloud Platform as a preview at the moment. It will be rolled out to other services soon.

• Go to Google Cloud Console -> Billing -> Your Billing Account -> Reports
• In "Filters", choose "Group by" as "SKU"
• Click "Download CSV". You can remove the price and usage colums from the CSV if you want before uploading.

We make a best effort attempt to detect the regions and services. You can edit them before saving.

Some common Google Cloud Platform products are highlighted in the list of components with a "(Suggested)" label even if they are not detected in your billing report. E.g. Virtual Private Cloud is something you would definitely use as it's a building block for a Google Cloud setup, but it's not something that might show up in your billing report.

Commonly Used Services​

When you login for the first time to your IncidentHub dashboard, you will see a list of services that are commonly used by most users. You can click on them directly to add them to your monitoring.

Test Channels​

This was a long-overdue feature that we ourselves wanted. When we add a channel (email, Slack, Discord, etc.), we want to make sure that it works. However, notifications only sent when there are incidents in any of the monitored services. The "Test Channel" feature allows you to test if your channel is working before adding it. It's available for all channels and across all subscription plans.

It sends a test notification to the channel. A Discord example is shown below:

Dashboard Improvements​

Services With Incidents​

Previously, the only way to see services with incidents was to click on the "Details" button, or look at the "Availability" page. We've now made it easier by displaying the services with incidents on top of the list with an indicator against each. Clicking on the indicator will open the same incident details popup as clicking on the "Details" button.

Reliability Improvements​

Alert Emails for Webhook Failures​

If you have a webhook channel configured, and IncidentHub is unable to deliver notifications to it due to the webhook endpoint not being available, it will send an email to the account owner. The email will include details of the error.

Bug Fixes and Robustness Improvements​

We have fixed several bugs in the service specific parsers that has made the incident detection more reliable. We have also added several improvements to make edge case handling more robust.

Last but not the least, we have a new, more attractive, pricing model for our monthly and annual subscriptions.

As always, you can request for features, let us know about bugs, or give us any other feedback on any of the following channels:

• Email us at support@incidenthub.cloud
• Use the "Talk to us" button in the dashboard

All logos and company names are trademarks or registered trademarks of their respective holders

This article is part of a series on setting up an end-to-end monitoring and alerting stack using Prometheus.

Continuing our series on setting Prometheus in a Docker container, we will add a Grafana instance to our Prometheus setup.

Please refer to the previous article where we use docker compose to run Prometheus and Alertmanager together as that forms the basis to run multiple related containers. We will add a container to run Grafana to the same compose file in this article.

• Introduction
• Adding a Grafana Container to our Docker Compose
• Adding a Dashboard
• Troubleshooting
  • My datasource "Save and Test" fails
  • I cannot see any data in my dashboard
  • Only some of the panels in my dashboard show data
  • If I restart my containers, the dashboard is gone
• Conclusion
• References

Adding a Grafana Container to our Docker Compose​

First, create a volume for Grafana's data:

docker volume create grafana-data

Now edit your docker-compose.yml in your prometheus directory and add the volume to the volumes section:

volumes:
    prometheus:
        external: true
    alertmanager:
        external: true
    grafana-data:
        external: true

We'll use the grafana-enterprise:11.4.0-ubuntu image to run Grafana. Under services, add the following:

  grafana:
    image: grafana/grafana-enterprise:11.4.0-ubuntu
    ports:
      - 3005:3000
    volumes:
      - grafana-data:/var/lib/grafana
    restart: always
    links:
      - prometheus:prometheus

We've added a link to the prometheus container so that Grafana can find and use Prometheus as a data source.

Your complete docker-compose.yml should look like this:

volumes:
    prometheus:
        external: true
    alertmanager:
        external: true
    grafana-data:
        external: true

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    volumes:
      - ./config:/etc/prometheus
      - prometheus:/prometheus
    ports:
      - 9000:9090
    restart: always
    links:
      - alertmanager:alertmanager

  alertmanager:
    image: prom/alertmanager:v0.27.0
    ports:
      - 9001:9093
    volumes:
      - ./alertmanager-config/:/etc/alertmanager/
      - alertmanager:/alertmanager
    restart: always
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'
      - '--log.level=debug'

  grafana:
    image: grafana/grafana-enterprise:11.4.0-ubuntu
    ports:
      - 3005:3000
    volumes:
      - grafana-data:/var/lib/grafana
    restart: always
    links:
      - prometheus:prometheus

Grafana should be accessible at http://localhost:3005. To login for the first time, use the default credentials:

• Username: admin
• Password: admin

Once logged in, go to http://localhost:3005/connections/datasources/new and choose "Prometheus". The only parameter we need to worry about here is the Prometheus server URL. Set it to http://prometheus:9090. How does this work? We've linked the Prometheus container to the Grafana container, so the Prometheus container is accessible at prometheus:9090. Click on "Save and Test" to test the datasource connection.

Your Grafana is now ready and linked to your Prometheus instance.

Adding a Dashboard​

There are hundreds of ready-made dashboards available for Grafana. Since we have only Prometheus's own metrics in our setup, we will use a dashboard to visualize our Prometheus metrics. If you have added other exporters to your Prometheus you can use their dashboards, or create one from scratch.

• Download the dashboard from https://grafana.com/grafana/dashboards/3662-prometheus-2-0-overview/
• Go to http://localhost:3005/dashboards and click on "New"->"Import"
• Click on "Upload dashboard JSON file" and select the file you downloaded.
• For "Choose a Prometheus data source", select the datasource you created earlier.
• Click on "Import" and you should see your dashboard.

Congratulations! You have just setup a dashboard to visualize your Prometheus metrics. From here, you can do much more:

• Setup other exporters for Prometheus and add dashboards for them.
• Monitor Alertmanager itself with its own dashboard.
• Grafana has a ton of other features including alerting, annotations, and integration with other monitoring tools.

Troubleshooting​

My datasource "Save and Test" fails​

• Check that the Prometheus server URL is correct. The name of the Prometheus host should match what is set under links in the docker-compose.yml for the grafana service, and the port should match the Prometheus container port - default being 9090.
• Check that the Prometheus container is running.

I cannot see any data in my dashboard​

• Check that you have the correct datasource set for the dashboard. One way to troubleshoot is to query the datasource directly from Grafana for a known metric.
• Edit one of the panels in the dashboard and check if you can see the metric. If not, then check if your Prometheus container is collecting metrics by checking the Prometheus UI.

Only some of the panels in my dashboard show data​

• This is most likely because some of the panels are querying metrics that don't exist

If I restart my containers, the dashboard is gone​

• Grafana stores the dashboard configuration in the grafana-data volume. If you deleted the volume, or changed its name in the docker-compose.yml, your setting will be lost.

Conclusion​

Grafana is a powerful dashboarding software that you can use to visualize your metrics from different sources, not just Prometheus.

References​

• Grafana Dashboards
• Official Grafana container images
• Docker Volume commands
• YAML Validator

You might also like:

• A Beginner's Guide To Service Discovery in Prometheus
• Sending Alerts Using Prometheus and Alertmanager
• Deploying Prometheus With Docker
• How to Configure a Remote Data Store for Prometheus

This article was originally published on the IncidentHub blog.

All product names, company names, logos and trademarks are the property of their respective owners. IncidentHub is not affiliated with any of the vendors mentioned in this article.

A status page forms a key part of your incident communication strategy. When it comes to setting up a status page, you have two options:

• Host your own - using either an open source project or a custom solution.
• Use a managed status page provider.

We will examine the pros and cons of each option along these dimensions:

1. Feature Set
2. Service Related

For 1, if you choose a self-managed, open-source or custom solution, it's in your control. For a managed solution, you are limited by the provider's feature set.

For 2, if you choose a self-managed solution, your team is responsible for the quality of the service. For a managed solution, you are dependent on the provider's service quality.

In most cases, you are better off using a managed solution from a reputed provider, unless you have:

• Specific requirements that are not met by the vendor.
• Budget constraints.

• Introduction
• Feature Set Considerations
  • Integration Options
  • Customizability
  • Reporting and Analytics
• Service Related Considerations
  • Cost and Maintenance
  • Availability
  • Support
• Conclusion

This article is not a comparison of specific managed vs self-managed status page providers but is meant to be a set of guidelines to help you make a decision.

Feature Set Considerations​

Integration Options​

A status page should be able to integrate with your existing tools and incident management workflows. The minimum integration options you should look for are:

• API access for updates. You would want the option of automatically updating the status page from your incident management tools, or manually updating it, depending on business needs.
• Easy integration with your existing toolset.

These options are for your SRE/Ops/IT Team so that they can keep stakeholders updated by either automatically or manually updating the status page.

For your end users, you would want to have options for them to subscribe to updates via email, SMS, Slack, Discord, or other channels.

Subscription options for GitHub's status page, which uses Atlassian Statuspage as a provider.

Some managed providers offer a complete stack of tools for monitoring, alerting, and status pages. However, if you have a monitoring stack already, you might not be able to use such providers since their status pages are usually tied to their monitoring solutions. In such cases consider using a standalone status page provider.

Some standalone status page options are:

• Atlassian Statuspage
• Instatus
• StatusHub
• Status.io
• StatusPal

If you are using an open source solution, you might be able to customize it to your needs. If you have a custom, homegrown status page, you are in complete control. The downside is that you need to spend time and resources to build as well as maintain it.

Customizability​

Your status page should reflect your branding as well as support your service's architecture.

Branding includes the logo, colors, other visual elements, and a whitelabeled URL. With both managed and open source solutions, you can customize the branding according to your needs.

A status page should also be able to represent your service components and regions, and different kinds of events. The former is especially important if you many services which are globally distributed. If you want to keep your users updated about upcoming maintenance, you would want to be able to represent that in the status page. Most managed providers offer this feature.

An example of a homegrown status page - Google Cloud Platform.

Depending on your business global presence, i18n support can also be a requirement.

During the beginning of an incident, it's possible your teams won't have much information to share about the outage. As they work towards mitigation, more information will become available. A status page should allow you to update accordingly, and maybe add more information to older entries for that incident.

Reporting and Analytics​

Every incident is an opportunity to learn. As part of your incident post-mortems, you can improve your incident response process by examining areas of improvement. Incident metrics can help you identify possible areas. Your status page software should be able to give you such metrics and reports.

Service Related Considerations​

Cost and Maintenance​

For a managed status page provider that meets all your needs, your only remaining consideration remains budgetary.

If you opt for a self-managed solution, you need to consider these costs:

• Ongoing bug fixes and improvements. If it's in-house, you have more control over the codebase.
• Hosting and availability costs.

Availability​

Your status page should have good availability. If you are using a managed solution, check that the provider has a good uptime record. They should also have a way of notifying you if there is an outage with their service.

An example of a status page provider's status page.

If you're self-hosting, it's your team's responsibility to ensure availability. A rule of thumb here is to keep the status page hosting logically and physically separate from the rest of your production environment. You should monitor the status page's availability and performance in the same way you monitor your production environment.

Support​

For a managed provider, check their SLA and support options.

For a self-managed solution, it's a good idea to have a dedicated owner - whether it's a person or a team - who is responsible for the status page.

Conclusion​

Deciding between hosting your own status page and using a managed solution ultimately depends on your organization's specific needs, resources, and priorities. A self-hosted status page offers greater control and customization, making it suitable for teams with unique requirements. However, it can also demands significant time and resources for development and maintenance.

On the other hand, a managed status page provider can outsource the headache of maintenance and availability. With the right provider, you can ensure high availability, robust support, and seamless integration with your existing tools.

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

Image credits: Photo by Image by Joshua Woroniecki from Pixabay

If you manage applications running on cloud platforms, you likely depend on multiple cloud vendors and services. These could be infrastructure providers like AWS, GCP or Azure. A vulnerability in any of these services could potentially impact your applications and your users.

A cloud platform has many moving parts, many of which are dependent on other third-party providers. For example:

• Operating system images for VMs which are maintained by third-party vendors.
• Container images which are hosted on external repositories.
• Software stacks which are maintained by other vendors but available for deployment on the cloud provider.
• Libraries used by the cloud provider's internal software which are maintained by other developers or organizations.
• Control plane software like Kubernetes.
• Hardware, like processors, which are provided by the manufacturer.
• Hypervisors which are developed and maintained by third-party vendors.
• Networking hardware manufactured by other vendors.

• Introduction
• Why Monitoring Cloud Vendors' Security is Important
  • Security Risks in Cloud Services
  • Real-World Examples
• How To Stay Updated About Cloud Vendor Security Issues
  • Links to Some Cloud Vendor Security Advisories
• Tools and Services to Monitor Cloud Vendor Security
  • RSS Feeds
  • Email Alerts
  • Cloud Dashboard Alerts
• Best Practices
• Conclusion

This guide is particularly relevant for:

• Ops/SRE folks managing cloud applications on cloud platforms.
• Security teams responsible for application security.
• Engineering managers and VPs overseeing cloud operations.

It is important to distinguish between the security issues affecting the cloud vendor's services and the issues affecting the applications running on the cloud. The cloud vendor is responsible for the security of its infrastructure, including:

• Mitigating vulnerabilities in its control, including datacenter, network, hardware and control plane software.
• Making patches available for third-party hardware and software that are part of its platform once they are provided by the third-parties. E.g hypervisors, processors, VM images.

The cloud vendor is not responsible for the security of the application code that users run on it. As a cloud user, you are responsible for that.

However, your responsibility as a cloud user also includes:

• Staying abreast of security vulnerabilities in the cloud vendor's infrastructure.
• Updating your applications to use the latest versions of the libraries and frameworks that you depend on.
• Updating to the latest and secure versions of the software stacks that you use but are provided by the cloud vendor. E.g. VM images, Kubernetes versions, etc.

We will cover the how to stay on top of security vulnerabilities in the cloud vendor's infrastructure in this article.

Why Monitoring Cloud Vendors' Security is Important​

Security Risks in Cloud Services​

Cloud vendors face security challenges that could impact your applications:

1. Infrastructure Vulnerabilities

   • Zero-day exploits in hypervisors.
   • Vulnerabilities in container runtimes.
   • Network protocol weaknesses.
   • Hardware-level security flaws.

2. Software Supply Chain Issues

   • Compromised dependencies being used by the cloud vendor's software.
   • Outdated and vulnerable third-party libraries.
   • Malicious container images.

3. Configuration Risks

   • Default settings that may be insecure.
   • Misconfigurations in service integrations, especially when services are developed by different vendors.
   • Access control weaknesses.
   • Gaps in API security.
   • Expired certificates.

4. Compliance and Regulatory Risks

   • Data privacy violations.
   • Regulatory non-compliance.
   • Geographic data residency issues.
   • Certification lapses.

Although Compliance and Regulatory issues are an important part of security, we will not cover them in this article because they are not directly related to the building blocks of the cloud vendor's infrastructure.

The impact of these vulnerabilities can be severe:

• Data breaches exposing sensitive customer and company information.
• Service disruptions affecting SLAs.
• Financial losses from security incidents.
• Damage to company reputation.
• Legal and regulatory consequences.

Real-World Examples​

Some recent incidents highlight the importance of monitoring cloud vendor security:

• Meltdown CPU vulnerability (2018).
• Spectre CPU vulnerability (2017).
• Solarwinds supply chain attack (2019-2020).
• Azure Cosmos DB vulnerability (2021).

How To Stay Updated About Cloud Vendor Security Issues​

Cloud vendors publish security advisories on their websites. These advisories are published in the form of blog posts, emails, and sometimes in the form of security bulletins. You can subscribe to these advisories to stay updated. You might also want to monitor vulnerabilities in the software stacks that you use. E.g. Kubernetes, Docker, etc. Even if you use managed versions of these, you can get to know about security issues before your cloud vendor reports it and releases an updated version of the stack.

Links to Some Cloud Vendor Security Advisories​

• AWS Security Bulletins
• Azure Security Advisories
• Google Cloud Security Bulletins
• Oracle Cloud Security Advisories
• IBM Cloud Security Advisories
• Red Hat Cloud Security Advisories
• Cisco Security Advisories
• Broadcom VMware Cloud Security Advisories
• Dell Security Advisories
• TencentCloud Security Advisories
• Fastly Security Advisories

These links are valid as of this writing (December 2024).

Based on the publicly available data in the above links, we can see trends in different cloud vendors' security advisories.

Source: Generated from the Google Cloud Security Bulletins page data.

Source: Generated from the AWS Security Bulletins page data.

Source: Generated from the Kubernetes Security Bulletins page data.

Note that there are multiple factors that affect the advisory count, and a rising trend does not necessarily mean that the cloud vendor is not doing a good job.

• The number of vulnerabilities in dependent software.
• The number of vulnerabilities in dependent hardware.
• The number of vulnerabilities actually discovered.

Tools and Services to Monitor Cloud Vendor Security​

When it comes to staying updated, there are different approaches. Choose the one that works for you.

RSS Feeds​

If the bulletin page has the option of subscribing to RSS feeds, you can use that to get updates. You can tie in the RSS feed to your email client or Slack channel.

Email Alerts​

If the bulletin page has the option of subscribing to email alerts, you can use that to get updates.

Cloud Dashboard Alerts​

If your cloud vendor has the option of sending you security notifications in your dashboard, you can use that. However, this has the drawback that you won't see the alert unless you are signed in and monitoring your dashboard.

Best Practices​

• Do periodic reviews of which security advisories you are monitoring. Your team(s) might have started using a new cloud vendor or dropped an existing one.
• If mitigation requires a migration - e.g. to new VMs, or a new version, track it like any other development task. This is especially important if you have many applications or a distributed architecture.
• When a security advisory is published, identify potential attack vectors in your applications and if possible test for them. You might have to take alternative measures until the vendor releases a patch.
• Maintain communication with stakeholders throughout the process.

Conclusion​

Keeping track of your cloud vendors' security updates and vulnerabilities is important to your business. It helps you ensure that your applications are not exposed to risk.

Image credits: Photo by Pawel Czerwinski on Unsplash

This article is part of a series on setting up an end-to-end monitoring and alerting stack using Prometheus.

Continuing our series on setting up Prometheus in a container, this article provides a step-by-step guide for how to configure alerts in Prometheus. We will add alerting rules and deploy Prometheus Alertmanager with Slack integration.

If you follow the steps in this article, you will end up with a containerized setup for:

1. A Prometheus instance with alerting rules.
2. An Alertmanager instance which can send alerts originating from those rules to a Slack channel.

Let's get started.

• Introduction
• Using Docker Compose
  • Moving the Prometheus Container to Docker Compose
• Adding Alerting Rules to the Prometheus container
• Setting up Prometheus Alertmanager
  • Setting up the Alertmanager Container
  • Link Alertmanager to Prometheus
• Troubleshooting
  • Useful Tip
• Conclusion
• References

Using Docker Compose​

Moving the Prometheus Container to Docker Compose​

In a previous article, we looked at how to setup Prometheus in a Docker container. We will now deploy Prometheus Alertmanager in a different container. To manage multiple containers with a single command, we will move our entire deployment to Docker compose.

In the prometheus directory (refer to the previous article), create a file called docker-compose.yml and add the following content to it:

volumes:
    prometheus:
      external: true

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    volumes:
      - ./config:/etc/prometheus
      - prometheus:/prometheus
    ports:
      - 9000:9090
    restart: always

This will keep the previous configuration file as well as the docker volume. To run this we need to have Docker compose installed. We won't go into the details of installing Docker compose as it's beyond the scope of this article. Note that we used external: true so that we can reuse the previous volume that we created.

Bring up the container by executing

docker compose up --detach

Access the Prometheus UI by visiting http://localhost:9090 as before. The --detach flag will run the containers in the background. To stop the container(s), execute

docker compose down

You can tail the logs of the running containers by using

docker compose logs --follow

Adding Alerting Rules to the Prometheus container​

Prometheus can process alert rules written in PromQL. Let's create a basic rule file that will alert if the cpu usage exceeds 20% and 80% for 1 minute, with different severity levels. In the config directory, create a file called alert_rules.yml with the following content:

groups:
- name: default
  labels:
    tier: infra
  rules:
  - alert: ModeratelyHighCPU
    expr: rate(process_cpu_seconds_total[1m]) > 0.2
    for: 1m
    keep_firing_for: 1m
    labels:
      severity: warning
    annotations:
      summary: Moderately High CPU
  - alert: VeryHighCPU
    expr: rate(process_cpu_seconds_total[1m]) > 0.8
    for: 1m
    keep_firing_for: 1m
    labels:
      severity: critical
    annotations:
      summary: Very High CPU

This defines two alerts on a metric process_cpu_seconds_total that fire based on whether the total CPU usage exceeds 20% or 80% for 1 minute.

The thresholds are just for illustration.

Note that we have assigned labels with different values for the severity key to the alerts. We will see how they are used to route alerts later in the Alertmanager configuration.

Now add this rule file's name to the prometheus.yml file so that the latter looks like this:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets:

rule_files:
  - "alert_rules.yml"

scrape_configs:
  - job_name: "prometheus"

    static_configs:
      - targets: ["localhost:9090"]

The path to the rules file is relative to the location of the prometheus.yml. You can also give an absolute path if it's somewhere else. Now restart the container and you should be able to see the rule in your UI at http://localhost:9000/rules

docker compose down
docker compose up --detach

This alert won't fire until it exceeds the threshold, and that will depend on how busy your machine is. So if you want to make sure it works you can change the threshold to a very low number like 0.0002 and test it. You can see the alert in http://localhost:9000/alerts.

Now that we have a rule engine that can generate alerts, we need a way to send these alerts to an endpoint like Slack or Email or PagerDuty to receive notifications. To do this, we will use Prometheus Alertmanager.

Setting up Prometheus Alertmanager​

Alertmanager is a Prometheus project that acts as a gateway between your Prometheus rule engine and external tools that can process alerts. You can configure routing rules as well as silence alerts in Alertmanager. At the end of this section you will have your Prometheus container sending alerts to your Alertmanager container.

Setting up the Alertmanager Container​

First, to keep things consistent, let us create a volume for alertmanager's data:

docker volume create alertmanager

Alertmanager will use this volume to store alert silences among other things. So if you silence an alert, and your Alertmanager container restarts, the silence will still be active.

Next, create a directory called alertmanager-config at the same level as prometheus. This will be our Alertmanager configuration directory. Inside it, create a basic alertmanager config in a file alertmanager.yml:

global:

# The directory from which notification templates are read.
# We won't be using this now
templates:
  - '/etc/alertmanager/template/*.tmpl'

route:
  group_by: ['service']

  group_wait: 30s

  group_interval: 5m

  repeat_interval: 3h

  receiver: team-slack

inhibit_rules:
  - source_matchers: [severity="critical"]
    target_matchers: [severity="warning"]

receivers:
  - name: 'team-slack'
    slack_configs:
      - api_url: '<webhook_url>'
        channel: '#<channel_name>'
        send_resolved: true

Replace the channel_name with the Slack channel where you want to receive alerts, and the webhook_url with a Slack webhook URL. Be careful not to commit this file with the webhook URL in it.

This configuration just routes all alerts into a Slack channel irrespective of their severity or other labels. In a later article we will see how to route alerts to different teams and channels based on labels.

Link Alertmanager to Prometheus​

Now add the Alertmanager configuration to the docker-compose.yml so that it becomes part of our Prometheus setup:

volumes:
    prometheus:
        external: true
    alertmanager:
        external: true

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    volumes:
      - ./config:/etc/prometheus
      - prometheus:/prometheus
    ports:
      - 9000:9090
    restart: always
    links:
      - alertmanager:alertmanager

  alertmanager:
    image: prom/alertmanager:v0.27.0
    ports:
      - 9001:9093
    volumes:
      - ./alertmanager-config/:/etc/alertmanager/
      - alertmanager:/alertmanager
    restart: always

We've added a link to the prometheus container so that it can find the alertmanager container.

Now there's one more piece to the puzzle. Prometheus should be configured so that it knows the Alertmanager endpoint to send to. Think of the link in the docker-compose.yml as an internal DNS name that is reachable by the Prometheus container. Modify the prometheus.yml file to add this under the alertmanagers key

global:
  scrape_interval: 15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

rule_files:
  - "alert_rules.yml"

scrape_configs:
  - job_name: "prometheus"

    static_configs:
      - targets: ["localhost:9090"]

We are referring to Alertmanager using the internal name and its default port. If you change the link name in docker-compose.yaml you have to change it here too.

Once you restart your containers, you should be able to access the Alertmanager UI at http://localhost:9001.

To test this end-to-end, modify your alert_rules.yml to lower the threshold. Within 1 minute (the value of "for" in the alert_rules.yml) you should see the alert message in your Slack channel.

Congratulations! You have just setup a minimal end-to-end alerting pipeline with Prometheus and Alertmanager. From here, we can do many more things:

• Setup advanced routing rules for Alertmanager, including routing to different teams on different channels, routing a subset of one team's alerts to another, and routing alerts of a certain severity to a different endpoint like PagerDuty.
• Add basic authentication and Google SSO to our Prometheus UI.
• Configure our own custom email templates for Alertmanager emails.
• Store secrets securely.

Stay tuned for updates on these topics.

Troubleshooting​

If you don't see any alerts in your Slack channel, follow this step-by-step guide to troubleshoot:

• Check all the config files including the docker-compose.yml and verify that they match what we have been walking through. You might want to run a YAML linter on all your files.
• Check the container logs for any errors. Run docker compose logs --follow
• Are all your containers running? Run docker ps to check.
• Is the alert firing in Prometheus? Check the Prometheus UI at http://localhost:9000/alerts.
• If yes, is the alert reaching Alertmanager? Check the Alertmanager UI at http://localhost:9001/#/alerts.
• If yes, is your Slack webhook URL correct? Is the channel correct? Note that the channel name should have a leading '#'.

If all of these things are correct, turn on debug for both Prometheus and Alertmanager in docker-compose.yml:

volumes:
    prometheus:
        external: true
    alertmanager:
        external: true

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    volumes:
      - ./config:/etc/prometheus
      - prometheus:/prometheus
    ports:
      - 9000:9090
    restart: always
    links:
      - alertmanager:alertmanager
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.path=/prometheus'
      - '--log.level=debug'

  alertmanager:
    image: prom/alertmanager:v0.27.0
    ports:
      - 9001:9093
    volumes:
      - ./alertmanager-config/:/etc/alertmanager/
      - alertmanager:/alertmanager
    restart: always
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'
      - '--log.level=debug'

This should result in more verbose output which should help you debug. If you are still stuck, reach out to me on Twitter and I'll try my best to help.

Conclusion​

Prometheus and Alertmanager together form a powerful monitoring and alerting stack. It's easy to setup for basic cases, but can require significant work for more sophisticated use-cases. This article is a guide to a basic setup of these tools.

References​

• Prometheus 3.0.0 documentation
• Alertmaanger 0.27.0 documentation
• Docker Container Management commands
• Docker Compose Installation
• Docker Volume commands
• YAML Validator

You might also like:

• A Beginner's Guide To Service Discovery in Prometheus
• Adding a Grafana Dashboard to Your Prometheus Setup
• Deploying Prometheus With Docker
• How to Configure a Remote Data Store for Prometheus

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: Elisa from Pixabay.