How to monitor a vendor's status page: five products, one board, and the incident title in every alert

Us or them

Every outage starts with the same question. The checkout is failing, the deploy is stuck, and before anyone opens a log someone asks whether it is us or them: the payment provider, the identity provider, the cloud host. The answer is on a page the vendor already publishes, and the habit is to open it in a tab, refresh it, and paste its link into the incident channel. That is monitoring by hand: it comes after your own alert, and nobody does it at three in the morning.

A vendor status page is a hosted page a company keeps for the services it sells: components with a word beside each one, the incidents currently open with their updates, and any maintenance in progress. Most vendors of any size run one, and a great many are built on one of a handful of products, which is what makes them watchable: each product publishes the page's state as JSON at a fixed path, so what a human reads in a browser a monitor can read on a schedule.

The five products

hostnag reads pages served by Statuspage, Instatus, Better Stack, incident.io and status.io. They differ in their words and in where their JSON lives; the monitor folds them into one vocabulary.

Statuspage, by Atlassian, carries an overall indicator plus a per-component status such as "partial outage" or "major outage". Instatus publishes a summary with the page's state and its active incidents, but no per-component levels. Better Stack and incident.io serve status pages beside their monitoring and incident products. status.io identifies each page by an id its HTML carries, and answers from an API of its own.

You do not need to know which one a vendor uses. Paste the page's address into the monitor wizard and detection works it out: hostnag probes a fixed set of paths on that origin, plus the id a status.io page's HTML names, and nothing else. It stores the product it found, the endpoint it will read, the page's name and, for status.io, that id. A page that answers but matches none of the five is reported as not recognised; one that does not answer at all says so. When the pasted host contains the word "status", the wizard puts the vendor check first in its list and ticks it for you.

The whole page, or the components you depend on

A big vendor's page lists dozens of components, and most of them are not yours: if you only use their hosted database, an outage in their object storage is noise. Detection returns the page's components, grouped as the page groups them, and you pick the ones you depend on. With a filter the verdict is the worst level among the selected components, and only incidents that name one of them count; an incident that names no components is kept, since it may be about everything.

Two limits follow from the products themselves. An Instatus summary carries no component levels, so detection offers none for an Instatus page and its watch is the whole page. And components come and go: when some you picked are no longer on the page, the monitor page says how many and the watch carries on with the rest; when every one has gone, the run is an error outcome rather than a permanent Operational, because that is a settings problem and not the vendor's health.

Their words become your words

Every product has its own words. hostnag reads them into four levels: Operational, Degraded, Outage and Maintenance. A Statuspage component under "partial outage" reads as Degraded and one under "major outage" as Outage; a page-level indicator of minor is Degraded and major or critical is Outage. Each provider's vocabulary has a mapping like that, and a component whose word hostnag does not know counts as operational rather than as a problem.

The monitor's status follows the level. Outage is Down. Degraded is Degraded. Maintenance and Operational are both Up: planned work shows on the monitor page as "Maintenance in progress" and raises nothing, because maintenance a vendor announced is not your incident. The read happens once per run from US East, and one run is enough to confirm: what the vendor says about their own service is the verdict, and there is nothing a second location could add to it.

The interval is the availability family's: every 5 minutes on the Free plan, every 1 minute on Pro and Business. A vendor's page is updated by a human, usually minutes after the trouble started, so the interval does not decide how quickly you hear; it decides how far behind the page you can be.

A page that cannot be read is not an outage

Status pages go dark too: the page host has its own bad days, a request times out, a page answers with an error, or the body is not the JSON hostnag expected. None of that says anything about the vendor's service, so none of it is Down. The run is a Couldn't check: the monitor reads that way on the board, the failed read is recorded with its reason, and a transient failure is retried once inside the run like every other check. If the page stays unreadable for three runs in a row, a warning says the checks are failing for that page, so you know the watch itself is blind. It never says the vendor is down when all it knows is that it could not ask.

That is the difference from an HTTP monitor pointed at a status page: one tells you the page loads, the other tells you what it says, and stays quiet when it cannot tell.

What the alerts say

Every alert carries the vendor's own words. At Outage the alert is Critical and its title names the monitor and the leading incident, "reports an outage: Incident with Actions" in the sample on the feature page; the body carries a link to the vendor's page, and the lines under it name the provider, the incident and the vendor page. While the outage lasts, reminders arrive on the group's down-reminder interval with the running duration, and when it ends a recovery notice says the vendor is operational again and how long the outage lasted.

Degraded raises a warning with the same shape, "reports degraded service" and the incident title, behind the group's degraded switch, which is off until you turn it on. A degraded vendor is worth seeing on the board without waking anyone; the switch is where you decide.

The incident title and link are what make the alert useful the moment it arrives. Your own HTTP monitor saying the payments API is down, and the vendor's row saying "Elevated error rates on card processing" two minutes later in the same channel, is the whole diagnosis.

Why it belongs beside your own uptime

Three reasons to watch a vendor's page from the board that holds your own hosts.

The pairing. Your own monitors see the failure first, because they measure your service and the vendor's page is written by people. The vendor row explains it a few minutes later, or fails to, which is itself an answer: a red vendor row means wait; a green one means the problem is yours.

The record. The vendor row has its own history and uptime, so when the review asks how often the payment provider was down, the answer is on a page rather than in memory. It is its own monitor with its own numbers, so a vendor's outage never touches your uptime.

The status page. A vendor row can be tracked on your own public status page, so your customers see the vendor's state from you rather than working it out from a failed checkout.

Look for yourself

The JSON a status page publishes is readable with curl: a Statuspage page's summary, then an Instatus page's, then a Better Stack page's, each printing the overall word and the open incidents.

curl -s https://status.example.com/api/v2/summary.json | jq '.status.indicator, [.incidents[].name]'
curl -s https://status.example.com/summary.json | jq '.page.status, [.activeIncidents[].name]'
curl -s https://status.example.com/index.json | jq '.data.attributes.aggregate_state'

Those are three of the paths detection probes when you paste a page. The words differ from one to the next, "none" against "UP" against "operational": that is the folding the monitor does.

Check it now, then watch it

Check it now: there is no public tool for this one, because the check is the vendor's own page. Run the curl line above against it and you are reading the same JSON hostnag reads.

Watch it for good: vendor status monitoring reads the page on your schedule, turns an Outage into Down and a Degraded into Degraded, and puts the incident title and link in every alert. The group's alert policy decides who hears, at which severity, and whether a degraded vendor pages anyone at all.