Third-party status monitoring, explained
Five vendors free, forever.
Third-party status monitoring means watching the health of services you do not run but depend on. It is sometimes called status page aggregation or dependency monitoring. The goal is simple: know about a vendor incident as soon as the vendor reports it, without checking dozens of pages by hand.
How it works under the hood
Most vendors publish a status page. Many of those pages are built on a handful of hosted platforms that also publish machine-readable data:
- JSON summaries listing components, their status and any open incidents
- RSS or Atom feeds of incident updates
- HTML pages for vendors that built their own and publish nothing else
An aggregator polls each source on a schedule, parses the result and compares it with the previous state. When something changes, such as a component moving from operational to degraded, it creates an event and sends alerts.
Why normalization matters
Every vendor uses its own words. One says "degraded performance", another "increased error rates", another "partial service disruption". Some list regions, others list products, others list both. A useful aggregator maps everything into one model:
- Vendor
- Component
- Status: operational, degraded, partial outage, major outage, maintenance
- Incident text and timestamps
With that in place, alerts look the same whatever the source, and filters work the same way for every vendor.
Limits you should know about
Status pages are human-updated. Vendors decide when to post. Some post within minutes; some wait until they understand the problem. No aggregator can report what a vendor has not published.
Status pages can be optimistic. Partial or regional issues are sometimes posted late or not at all.
Formats change. Vendors move status pages or switch platforms. A good aggregator notices when a source stops returning data.
To reduce these gaps, Outage Clock adds its own simple reachability check of each vendor's homepage or API. It will not catch a subtle partial issue, but it flags a full outage even when the status page is quiet.
What to look for in a tool
- Coverage of your vendors. Check that your critical services are listed.
- Component and region filters. Essential for large cloud providers.
- Polling interval. Every few minutes is typical. Faster than a minute adds little, because vendors rarely post that quickly.
- Alert channels. Email, Slack, Teams and webhooks cover most teams.
- Resolution messages. Knowing when it is over matters as much as knowing it started.
- A dashboard or page for non-engineers. Support and IT need a quick view too.
- Price per vendor. Costs vary a lot between tools.
Polite polling
Status pages are public, but they are still someone's infrastructure. We poll at modest intervals, cache results and share each poll across all customers who follow that vendor, so one hundred customers following GitHub still means one request per interval.
When to build your own
If you follow three vendors that publish RSS, a chat app's feed integration may be enough. Past that, maintaining parsers, filters and alert formatting becomes a side project nobody wants to own.
Questions
Is this the same as uptime monitoring?
No. Uptime monitoring checks your own services. Third-party status monitoring checks the services you rely on.
Can I add a vendor that is not in your list?
Email support with the vendor's status page address and we will look at adding it.