Status page monitoring, done for you
Vendor status pages are a signal almost nobody's using well. Pingoru watches 6,116+ of them on a 5-minute cycle, translates ~40 different formats into one common shape, and fires alerts the instant a vendor publishes.
5 monitors free forever · No credit card
Three incidents picked up by status-page monitoring — GitHub, Stripe, and Cloudflare. All three landed in the feed within 5 minutes of the vendor posting them.
The mechanics of status page monitoring
Most SaaS and cloud vendors publish a public status page. Many of those pages also publish a machine-readable feed (typically JSON or RSS) so other tools can read them programmatically. A status-page monitor checks every vendor's feed on a fixed schedule, compares each response to the previous one, and writes any changes down.
It sounds trivial and is in fact quite hard at scale: vendors rate-limit, formats change, new vendors appear, old ones rename things, incidents get edited in place rather than appended. Pingoru does all that plumbing for you.
Every 5 minutes
Every provider checked every 5 minutes. Time from a vendor publishing to your alert landing: about 3 minutes on average.
~40 status-page formats
Most SaaS vendors publish in one of a handful of common formats and we read all of them. The bigger players (AWS, GCP, Azure, Salesforce, Apple, Heroku, Microsoft 365, PlayStation, plus ~25 others) publish in their own formats and we've written code specifically for each one.
Per-service detail
Where a vendor breaks itself down into specific services (EC2 us-east-1, Stripe Checkout, Slack Huddles), we capture each one individually — so your monitor can filter to just the services you actually use.
Edit-aware timeline
Vendors frequently edit the body of an open incident to add updates. We treat edits as new timeline entries rather than silently overwriting — so the full story is preserved for post-incident reviews.
Polite to shared backends
Thousands of status pages are hosted on the same handful of services. We limit how many we check at once per host so we don't accidentally hammer them or cause issues for the other sites using the same backend.
No ghost incidents
When a vendor drops an incident from their active feed without ever marking it resolved (AWS does this), we auto-resolve it after a grace period so your dashboard doesn't carry stale "open" incidents indefinitely.
Frequently asked
What does it mean to 'monitor a status page'?
Continuously checking a vendor's public status page for changes — new incidents, updated incidents, resolutions, maintenance windows — and notifying a human when a change happens. The mechanic is simple (GET the status-page JSON, diff against last fetch); the hard parts are doing it reliably across thousands of vendors with slightly different response shapes, rate limits, and outage patterns.
Can't I just set up RSS alerts for each vendor's status page?
Most status pages publish an RSS feed, so in theory yes. In practice managing 30+ feeds in an RSS reader — with no component filters, no deduplication across vendors, no resolution handling, no Slack/webhook routing — turns into a project nobody has time to maintain. A dedicated status-page monitor does that layer for you.
How often does Pingoru check each page?
Every 5 minutes. We spread the checks across ~6,116 providers with limits per shared host so we don't accidentally pile traffic on whoever's hosting their pages. Median time from a vendor publishing to an alert landing in your channel: ~3 minutes.
What status page formats can Pingoru read?
Pretty much all of them. Most SaaS vendors publish a machine-readable feed and we read it directly. The bigger players (AWS, Azure, GCP, Salesforce, Apple, Microsoft 365, Heroku) publish in their own formats, and we've written code specifically for each one. Anything else falls back to generic RSS or plain-HTML readers. ~40 different formats in total.
What happens when a vendor edits an incident update after posting it?
We treat in-place edits as new timeline entries rather than silently overwriting the original. Each update is keyed by a hash of its body content, so if the vendor adds a sentence to an existing update, that shows up as a new timeline row with its own timestamp. Preserves the full narrative history, which is useful for postmortems.
Can you monitor a status page that's behind authentication?
Not in v1 — we check pages anonymously. Status pages gated behind a login (Okta, Docker, ConnectWise, Fastly customer portals) fall back to reading the public landing page, which gives us a rough status but not per-service detail. Full authenticated checks using customer-supplied tokens are on the roadmap.
Related: cloud status monitoring, SaaS monitoring, root cause analysis (using vendor status during an incident), status page aggregator (combines many pages into one dashboard), status aggregation (the product category).
Every status page, watched for you.
Free forever for 5 monitors. No credit card. Email + signed webhook on every plan.
Start monitoring free →