IncidentHub posts related to the product
View All TagsOver 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.
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.
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.
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.
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.
Updated Mar 26, 2025
Staying on top of your third-party Cloud and SaaS service outages is crucial to maintaining the reliability of your own applications. Like many modern teams, Slack might be your communication tool of choice. You can keep up with such incidents by pushing these events to a Slack channel.
IncidentHub has its own Slack app which can be used to push incident lifecycle events to the Slack channel of your choice. It can be used to send incident trigger, update, and resolve events.
You must have the correct permissions on your Slack workspace to be able to do this.
Follow these steps to configure the Slack app in your Slack workspace.
Staying on top of your third-party Cloud and SaaS service outages is crucial to maintain the reliability of your own applications. If Discord is your communication tool of choice, you can keep up with such incidents by pushing these events to a Discord channel.
Discord webhooks allow external applications to send messages to specific channels within a Discord server. This article describes how to integrate Discord as a channel in your IncidentHub account using webhooks.
Chances are, most of your third-party cloud and SaaS dependencies are globally distributed and have many regions of operation. Chances are, your applications use a subset of a cloud or SaaS service. If you are monitoring such a service, why should you receive alerts for all regions or every single component in the service?
E.g. if you use Digital Ocean, you might be using Kubernetes in their US locations (NYC and SFO). You would want to know only when there is an outage in one of these locations. Digital Ocean's status page gives you the option to subscribe to outages across the board - it’s all or nothing. This is the case with most services with a few exceptions.
You can now choose which components/regions you wish to monitor in IncidentHub. Let us continue with our Digital Ocean example.
You can choose to monitor all components:
Why should you monitor your third-party Cloud and SaaS vendors if you are in SRE/Ops?
As part of an SRE team, your primary responsibility is ensuring the reliability of your applications. What makes you responsible for monitoring services that you don't even manage? Third-party services are just like yours - with SLAs. And outages happen, affecting you as well as many others who depend on them.
It's a no-brainer that you should know when such outages happen to be on top of things if/when it affects your running applications.
Most of your third party dependencies will have a public status page or a Twitter account where they publish updates on their outages. Here are some seemingly easy ways to monitor these pages
If you have a software-based business, you are using at least a few cloud based tools. It does not matter if you are a solo developer, or part of a 50-member team in a large organization. Take this random list and chances are you are using at least half of them:
Your entire business - irrespective of org or market size - including your development tools, collaboration/communication tools, infrastructure and hosting, monitoring, even email - is dependent on services that you don’t control. They are provided by other vendors.
Of course, you pay for some of them and they all have SLAs. Having an SLA does not translate to 100% uptime. Companies will try their best to meet SLAs - which promise a percentage of uptime (usually 99.xx). There are going to be incidents in your providers at some point, and the effect will cascade to the service that you provide to your customers. This means that your own product's SLA can be breached due to causes outside your control.
