Provider Status Board
A provider status board is a single page that collects the public status pages of the services your own site depends on, so one glance answers the first outage question: is it us, or is it them? This board loads a fresh snapshot from the major providers on open — no URL to enter — and shows each provider’s own status wording, its active incidents and its scheduled maintenance. The companion guide, when your provider goes down, explains how to read an incident like an operator; if the board says everyone is fine but your users still cannot reach you, run the Website Health Check or test reachability from other regions with Global Ping.
Last updated:
Want this watched continuously? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
How the board works
On page load the board asks the SysOSX checker for one aggregated snapshot. The checker reads the public status feeds the providers publish for their own status pages — the same machine-readable summary behind pages such as the GitHub and Cloudflare status sites — and returns, for each provider, its overall indicator, its own description of that indicator, any incidents currently open and any maintenance windows already scheduled. Results are cached for a few minutes, because a status page that changed thirty seconds ago does not need a thousand browsers hammering the provider’s feed; the snapshot shows when it was checked and carries a cached badge when you are looking at the cached copy. The refresh button asks for a fresh copy and bypasses that cache.
Nothing on this board is our opinion. The description on each card is the provider’s own wording, reproduced verbatim, and the incident names, impacts and workflow states come straight from the provider’s feed. What the board adds is aggregation and translation of the scaffolding: the six possible indicators are mapped onto plain chips — operational, degraded performance, partial outage, major outage, maintenance and unknown — so providers that use different vocabularies for the same underlying state still read consistently side by side. When a provider’s feed cannot be read at all, its card says unknown rather than guessing operational, because a board that cries “fine” without data is worse than no board at all.
Reading the board during an incident
Start with the summary band. It counts how many of the tracked providers are fully operational and names the worst current status anywhere on the board, so a single critical provider stands out even when the other cards are green. Then read the affected provider’s card in full: the incident name usually names the component or region involved, the impact field says how much of the service the provider believes is affected, and the status field says where the incident sits in its own workflow — investigating, identified, monitoring or resolved. A long incident in monitoring is a very different signal from a fresh one in investigating, even when both cards carry the same coloured chip.
Use the provider picker to make the board yours. Every stack depends on a different subset of these services, and a board showing providers you do not use trains you to ignore it. Untick the providers that are not in your stack and the board hides them; your selection is stored in this browser, on this device, and survives reloads, and the show-all button restores the full board in one click. The summary band always describes the whole board, not only your selection, so hiding a provider never hides a widespread event: if a provider you unticked suffers a major outage that takes half the internet with it, the worst-status line still tells you.
Honesty limits: this board is a snapshot of what providers say about themselves, taken at the moment shown, and providers are sometimes slow to declare an incident, quick to declare one resolved, or precise about a component your site does not use while vague about the one it does. A green board does not prove your site is reachable — your region, your DNS path or your specific plan tier can be down while the global indicator stays green, which is exactly the gap the Global Ping test and the companion article explore. Treat the board as the fastest first answer to “is it just us?”, not as the last word, and always confirm against your own monitoring before you tell users the problem is elsewhere.
What the board shows, and the rules behind it
| Indicator: none | The provider reports no current problem. The card shows its own description verbatim — usually a form of “all systems operational” — and the chip reads operational. None is the only state counted as operational in the summary band. |
| Indicator: minor | A degraded service: something is slower, erroring intermittently or partly reduced, but the service broadly works. Shown as degraded performance. Most minor states are worth knowing about and few are worth waking anyone for. |
| Indicator: major | A partial outage: a significant part of the service — a region, a product or a class of requests — is failing for many users. Shown as partial outage. If the affected part overlaps your stack, treat it as your incident too. |
| Indicator: critical | A major outage: the provider considers the service broadly down or unusable. Shown as major outage, ranked as the worst state on the board, and always named in the summary band’s worst-status line while it lasts. |
| Indicator: maintenance | Planned work is in progress or the service is in a declared maintenance state. Maintenance is not an outage, but it explains elevated errors during the window, which is why scheduled windows are listed on each card before they begin. |
| Indicator: unknown | The checker could not read the provider’s status feed, so the board shows unknown rather than inventing a state. Unknown means “no data”, never “probably fine” — check the provider’s own status page directly when it matters. |
| Incidents | Open incidents are listed per provider with the provider’s own name for them, their declared impact, their workflow status and their last update time. Resolved incidents drop off the board; the provider’s status page keeps the full history. |
| Caching — 4 minutes | Snapshots are cached for about four minutes so a popular board does not hammer the providers’ feeds. The checked-at time and the cached badge tell you exactly how fresh what you are reading is; refresh bypasses the cache once. |
Frequently asked questions
The board says a provider is down, but the service works for me. Why?
Because status is not uniform. An incident can affect one region, one product surface or one class of request while the rest of the service — including the part you just used — works normally. Read the incident name on the card: it usually names the component or region involved. The reverse also happens: the board can be green while your region or tier is broken, because the provider’s global indicator summarises the whole service, not your slice of it.
How fresh is the data on this board?
Each snapshot is stamped with the time the checker took it, shown above the provider grid. Snapshots are cached for about four minutes, and a cached snapshot carries a cached badge so you never mistake it for a live reading. Press the refresh button when you need the current state — it bypasses the cache and fetches a fresh snapshot. During a fast-moving incident, also open the provider’s own status page, which updates continuously.
Why does a provider show “unknown”?
Unknown means the checker could not read that provider’s public status feed for this snapshot — the feed timed out, returned an error, or answered in a shape the checker does not recognise. It deliberately does not guess: unknown is displayed instead of a stale or invented state. Try a refresh; if the card stays unknown, go to the provider’s status page directly, because “no data” must never be read as “no problem”.
Can I choose which providers the board shows?
Yes. The checkboxes above the board list every tracked provider; untick the ones that are not in your stack and their cards disappear. Your selection is saved in this browser’s local storage, so the board comes back the way you left it, and the show-all button clears the selection and restores every provider. The summary band always covers all providers, so a hidden provider’s major outage still shows in the worst-status line.
What should I do when a provider I depend on goes down?
First, confirm the incident overlaps what you use — component, region and product — by reading the incident on the provider’s card and status page. Second, tell your users early and plainly that a named upstream provider is having an incident and what it means for them. Third, stop deploying and stop retrying aggressively; both make recovery harder. The companion guide, when your provider goes down, walks through the first ten minutes in order.