Cloud Outage Monitoring
Cloud outage monitoring is watching third-party cloud providers for the incidents and maintenance they publish on their public and private data sources like status pages and health APIs. It is not a probe of your endpoints, and it is not a synthetic test of your application. Status feed monitoring inherits the provider's reporting delay: you cannot detect an outage the provider has not yet posted.
Monitoring the Cloud - Three Different Types
Teams often say "we monitor the cloud" when they mean three different types of monitoring. They detect different failures and they miss different failures.
1. Monitoring a Provider's Status Feed
You poll or subscribe to what the provider publishes: a status page, an RSS or JSON feed, a webhook, an account-scoped Health API, or an authentication-gated health dashboard. You detect declared outages, updates, and scheduled maintenance for services and components the provider is willing to name. Anything not covered - silent tenant-specific faults on a public-only setup, delayed acknowledgments, and impact the provider has not classified yet - is beyond the scope of this approach.
2. Probing Your Endpoints
You hit URLs or endpoints you own, on a schedule, from one or more locations or networks. You detect that your check failed: DNS, TLS, HTTP status, or latency past a threshold. Your own telemetry might show issues that are attributable to underlying provider issues. You miss provider faults that do not land on those URLs, regional issues outside the probe's path, and the difference between "our app is wrong" and "AWS is wrong." A failed probe is often a symptom, but not a vendor attribution.
3. Synthetic Monitoring from Outside Your Network
Your own synthetic monitoring scripts mimic a user journey - login, payment, upload - from locations that are not your VPC. You can detect broken multi-step flows that a simple HTTP check would pass. You miss faults that do not occur on the scripted path, and you still do not know whether the break is in your code, your identity provider, or the cloud under it. Synthetic checks are good at user-visible breakage and from that perspective they have high value, because they measure what your users see. They do not measure your cloud providers.
Outage Classes by Monitoring Domain
| Outage Class | Monitoring Domain |
|---|---|
| Provider-declared, multi-customer incidents and scheduled maintenance | Public status feed monitoring |
| Your applications, your load balancer, your certificates | Endpoint probes and synthetic checks, plus your APM |
| Account-scoped cloud faults that may or may not appear on the public status page | Authenticated Health APIs scoped to your account |
How Cloud Providers Report Outages
A status page is an operational communications tool. It is updated under incident pressure, by on-call teams who are also trying to fix the outage.
How the Status Page Evolved
Early cloud status pages were hand-edited HTML. Someone in the NOC updated a paragraph when they had a moment. That is insufficient for a global incident. Atlassian Statuspage and subsequent services turned the page into a product: components, incident updates, subscriber email, an RSS feed, a JSON API, and more. Most SaaS providers use a third-party status page, while some roll out their own. AWS, Azure, and Google Cloud each run a bespoke status page system.
Provider Data Sources
| Provider | Data Source |
|---|---|
| AWS | AWS publishes a public AWS Health Dashboard at health.aws.amazon.com. The account-scoped Health Dashboard in the AWS console (after you log in) tells you what affects your account. |
| Microsoft Azure | Microsoft Azure publishes Azure Status as the public page. Azure Service Health, in the portal, is the account-scoped view: subscription, region, service, and resource. |
| Google Cloud | Google Cloud publishes Google Cloud Service Health. Personalized Service Health in the Google Cloud console is the project- and resource-scoped counterpart. The public page is selective. IncidentHub's H1 2026 report recorded 2 public GCP incidents versus 14 each for AWS and Azure over the same six months. That is not a reliability ranking but a difference in how the providers report outages. |
| Cloudflare | Cloudflare publishes on cloudflarestatus.com, a custom status page, with components down to products and many edge locations. Granularity is very much visible here: a single PoP incident is a row. In H1 2026, it reported 487 outages on the public page. A localized PoP issue is one outage in that count. An equivalent scale issue at a different provider that only posts widespread events would go unreported. |
Account-Scoped Cloud Outage Monitoring
Account-scoped feeds surface what public pages omit: a storage account in one subscription, a quota, or a maintenance that only your resources were scheduled for. Public pages surface what may or may not affect you: a region you do not use, a product you never enabled, an outage that does not affect your applications. Treating the public page as "my outage detector" can produce false negatives. Treating every public incident as "we are down" produces false positives. You still need the public feed to be aware of widespread issues, and the account-scoped feed for your tenancy. You also need filters on both. Some providers do not have an account-scoped feed - so you have to monitor the public feed.
Reporting Lag
Status feed monitoring inherits the provider's reporting delay. The H1 2026 Cloud and SaaS Reliability Report measures duration from the provider's first incident acknowledgment (which is not necessarily the same as the beginning of the incident) to its resolution timestamp - not from the first customer-visible error. The same report notes that provider-reported resolution can lag actual restoration because of internal checklists.
Component Granularity
An outage can be reported for one service or region for a provider, and the provider's status page can show the overall status as red. AWS can be having a service degradation because EC2 in us-west-2 has capacity problems, while all other AWS services in all other regions are operational. Component-level data exist in feeds so that you can be notified of only those outages that affect your applications.
Scheduled Maintenance - a Separate Signal
Outages are unplanned. Maintenance is usually announced beforehand (unless it's emergency maintenance), has a predefined window, and is scoped to specific services or regions. Mixing outages and maintenance can create a lot of alert noise. Knowledge about upcoming maintenance can help you prepare for any possible issues, but your monitoring should differentiate between outages and maintenance by using a different notification channel.
Why Status Pages Are Hard to Keep Accurate Mid-Incident
During an incident, the people who would update the page are the people debugging routing, capacity, or a bad config rollout. Early updates are scoped too narrowly, then widened. Recovery is posted, then sometimes walked back. Downstream vendors copy the upstream message hours later, or never name the upstream vendor at all. The CloudFront timeline shows live updates still describing recovery as in progress after the retrospective summary had already marked full recovery.
Cloud Outage Monitoring Approaches
| Approach | Coverage | Detection Latency | Alert Accuracy | Ongoing Effort | Cost |
|---|---|---|---|---|---|
| Manual status page checks | Detects outages in whichever vendor's status pages you remember to open, but misses the rest of your stack. | Can be hours, if someone is looking at the status pages periodically. | You notice an incident only after you load the page. | High. Does not scale past a handful of vendors. | Engineering time. Looks free until an incident is missed. |
| RSS or Atom feeds into Slack | Vendors that publish an RSS or Atom feed. | Feed polling interval plus the provider's own post delay. | Low. No component filter, no maintenance split, mostly every update for every region. It's a running feed - no snapshot view. | Low to set up but can quickly become noisy and thereafter ignored. Channels end up getting muted. | Free, until the channel is ignored. |
| Provider-native alerting | Single cloud - AWS Health events, Azure Service Health alerts, GCP Personalized Service Health. Nothing else in the dependency graph outside that cloud. | Good for that one cloud. Account-scoped events will show up for your account based on when the provider posts them. | High within that cloud. You still get noise unless you filter by service, region, and event type. | One console per cloud, plus IAM and routing to maintain. | Included in your cloud bill. |
| Endpoint probing tools | Your URLs from the probe's vantage point. Does not include the provider's other customers, or components you do not probe. | Probe interval. Can be seconds if your system can handle it. | Tells you that your check failed but not the underlying cause. | Checks, regions, auth, and flapping thresholds to maintain. | Per-check pricing that grows with endpoints and locations. |
| Status page aggregators | The public status pages the aggregator monitors, plus any private feeds it supports. | Provider post delay plus aggregator poll interval (typically a few minutes). | Depends on component filters, maintenance filtering, and alert routing. | Select services and components and set up alerting or a unified status page once. Format, URL, and other changes are the aggregator's problem. | A subscription. |
Status page aggregators exist because the dependency graph is wider than what one cloud console can show. The advantage is normalized outage coverage across vendors with one routing layer. The limit is defined by the source: you see what was posted, after it was posted, for the vendors the aggregator monitors.
Questions
How do I monitor cloud service outages in real time?
You can watch the provider's published status page. Subscribe to the official page, enable provider-native health alerts for the clouds you run in, or use a status page aggregator that polls those feeds, normalizes the data, and routes the result. 'Real time' here means minutes after the provider posts, not seconds after the first customer is affected. Status feed monitoring inherits the provider's reporting delay.
Where can I compare cloud providers by uptime?
IncidentHub's historical view of each service in the Availability dashboard shows you uptime of each provider you monitor.
Are provider status pages reliable?
They are the canonical public record of what the provider is willing to say. They are not a complete record of customer impact. Public pages omit tenant-specific incidents; account-scoped dashboards omit incidents that do not affect you; both can lag the first user-visible error by minutes to hours.
How do I tell whether an outage affects my account?
For providers that offer account-scoped health data, like AWS, Azure, and Google Cloud, the account-scoped Health views show health data specific to your resources. Correlate that with your own probes if you need to know whether your application is actually failing.
How do I monitor a vendor with no public status page?
If the vendor exposes a private health API, an SSO-gated status page, or a tenant-scoped dashboard, you can set up ingestion. IncidentHub does this for Infor CloudSuite, Microsoft 365, and Microsoft Azure on the Business and Multi-Client plans, in addition to monitoring the public status pages for Microsoft 365 and Azure.
How do I avoid alert fatigue from outage feeds?
Filter by component, split maintenance from outages, and route by team. Do not pipe a raw AWS or Cloudflare RSS feed into a shared Slack channel. For low-criticality vendors, take start and end events only. For high-criticality vendors, take all updates. Turn maintenance alerts off where you do not plan around the window.
What detection latency should I expect?
There are two factors. The first is the provider's reporting delay, and the second is the poll interval of whatever is watching the page, typically a few minutes for an aggregator.
Is provider-native alerting enough?
It is enough if you run inside one cloud and have health alerts routed correctly, and if you have no SaaS or identity dependencies outside that cloud. Most teams have multiple external dependencies. Provider-native alerting is localized to one cloud. It does not extend across the rest of the dependency graph.
What is the difference between Microsoft Azure's public status page and Azure Service Health?
Azure Status is the public page. It lists platform-wide incidents Microsoft has chosen to publish. Azure Service Health is account-scoped: subscription, region, service, and resource.
What does status feed monitoring not detect?
Anything the provider has not posted, including silent tenant-specific failures on a public-only setup, and anything wrong in your own application, network, or configuration. It also does not tell you whether your users are affected.
Further reading
Stop being in the dark about the status of your third-party services
IncidentHub is not affiliated with Amazon Web Services, Microsoft, Google, Cloudflare, GitHub, Stripe, Slack, or any other vendor named on this page. All logos and company names are trademarks or registered trademarks of their respective holders. This page is independent and is not endorsed by those vendors.
The canonical source for a provider's current status is that provider's own status page or Health dashboard. IncidentHub mirrors published feeds. It does not replace them.