Status page aggregator

A status page aggregator collects the official status pages of every vendor you depend on and shows them in one place — component by component, region by region, with alerts when something changes. PulsAPI tracks 2461 services this way.

Live right now

Server-rendered from the same pipeline that powers every PulsAPI status page. Regenerated at most once an hour.

VendorCurrent statusCategoryStatus page
CloudflareDegradedcdnIs Cloudflare down?
AWSPartial outagecloudIs AWS down?
CloudFrontOperationalcdnIs CloudFront down?
GitHubOperationaldevtoolsIs GitHub down?
StripeOperationalfintechIs Stripe down?
AkamaiDegradedcdnIs Akamai down?
Cloudflare WorkersPartial outagecloudIs Cloudflare Workers down?
ZoomOperationalcommunicationIs Zoom down?

Status aggregation is not uptime monitoring

These get conflated constantly, and they answer different questions. Most teams need both.

Uptime monitoringStatus page aggregation
What it watchesAn endpoint you controlWhat the vendor publishes about itself
AnswersIs it responding?Which component, which region, since when
Knows aboutYour own surfaceVendors you never call directly
During an incidentTells you something brokeTells you whose it is
Blind spotVendor-side degradation you cannot probeWhatever the vendor chooses not to publish

What aggregation buys you

Component-level detail, not one global light

A vendor being 'degraded' rarely means all of it. PulsAPI tracks each published component separately, so you can watch the one API you actually call instead of the whole provider.

Regions tracked independently

An incident in one region is not an incident in yours. Where a vendor publishes regional breakdowns, PulsAPI keeps them separate rather than collapsing them into a single verdict.

Incidents with timelines

Each incident keeps its detection time, the vendor's own updates, and its resolution, so a postmortem does not depend on someone having screenshotted a status page at the right moment.

Alerting with routing rules

Route by service, component, and severity to Slack, Discord, Microsoft Teams, PagerDuty, webhooks, or email, with cooldowns so one flapping vendor does not bury the channel.

Uptime and SLA history

30, 60, and 90-day uptime per service and per component, recorded continuously, so an SLA conversation starts from data rather than from memory.

Dependency impact mapping

Link vendors to the capabilities they support, so an incident reads as 'checkout is affected' rather than as the name of an infrastructure component nobody outside the team recognises.

Compared with checking status pages by hand

Manual checking is free and works fine at small scale. It stops working for a specific, measurable reason.

It only works when you are already lookingA status page tells you nothing at 3am. Aggregation is useful precisely because it watches when you are not.
Every vendor defines 'degraded' differentlyComparing across providers means normalizing their vocabularies first. That is work you would otherwise do in your head, inconsistently.
History disappearsMost vendor status pages show current state and a short incident list. Reconstructing 90 days of uptime after the fact is not possible from the page alone.
The honest limitationAn aggregator can only report what vendors publish. If a provider under-reports an incident on its own status page, that under-reporting propagates. PulsAPI adds a direct reachability check where no status page exists, but it is not a substitute for the vendor's own component detail.

Popular vendor status pages

Common questions

What is a status page aggregator?

A status page aggregator collects the official status pages of the vendors you depend on and presents them in one view. Instead of opening a tab per provider, you see every dependency's current state, component-level detail, and open incidents in a single place, with alerting when something changes.

How is a status page aggregator different from uptime monitoring?

Uptime monitoring pings an endpoint you control and tells you whether it answered. A status page aggregator reads what the vendor itself publishes: which component is affected, which region, when the incident opened, and how the vendor is describing it. They answer different questions. Uptime monitoring tells you something is wrong; aggregation tells you whose fault it is and what else it touches.

Why not just check each vendor's status page?

You can, and for two or three vendors that is fine. The cost is linear: every provider has its own URL, its own layout, its own definition of 'degraded', and its own component naming. PulsAPI normalizes those into one schema so a Statuspage JSON feed, an RSS feed, and a hand-rolled HTML page produce comparable records.

Does PulsAPI cover vendors that have no status page?

Some of them. Where a vendor publishes nothing machine-readable, PulsAPI falls back to a direct reachability check against the service itself. That is a weaker signal than a published component breakdown and it is labelled as such — a global up/down rather than per-component detail.

How often is vendor status refreshed?

The crawler polls vendor status pages every 60 seconds. Detected changes reach Slack, Discord, Microsoft Teams, PagerDuty, webhooks, or email in a few seconds. The live examples on this page are server-rendered and regenerate at most once an hour.

Aggregate your stack's status pages

Start on the free Starter plan, or take a 30-day Business trial with no card.