vendor-status-mcp — 1,100+ SaaS status pages as an MCP server
1,127 vendor status pages mapped · 804 with a machine-readable feed · 15,418
incidents on record · polled every day · no API key · zero dependencies.
(counts as of 2026-09-15 — dataset_status returns today's.)
Every SaaS and cloud vendor publishes a status page, and almost every one of them is on a different system — Atlassian Statuspage, Instatus, status.io, Better Stack, incident.io, or something home-grown. Vendor Status Watch keeps a living map of where those pages are, which ones expose JSON/RSS, and polls all 804 readable ones daily into one normalized incident history. This is that dataset wired into the Model Context Protocol, so Claude, Cursor, Continue or your own agent can ask questions like:
"Is Cloudflare having an incident right now?" "Which of our vendors — Stripe, Twilio, Datadog, Auth0 — had incidents this month?" "How long do GitHub incidents usually take to resolve?" "Does Vendor X have an RSS or JSON status feed, and where is it?" "What SaaS vendors are reporting a major outage today?"
Install
Nothing to build and nothing to install into your Python environment — the server is standard library only.
Claude Desktop / Claude Code / anything that reads an mcpServers block:
{
"mcpServers": {
"vendor-status": {
"command": "uvx",
"args": ["--from", "git+https://github.com/APVentureEngine/vendor-status-mcp", "vendor-status-mcp"]
}
}
}
Claude Code, one line:
claude mcp add vendor-status -- uvx --from git+https://github.com/APVentureEngine/vendor-status-mcp vendor-status-mcp
No uv? Clone and run it with plain Python:
git clone https://github.com/APVentureEngine/vendor-status-mcp && cd vendor-status-mcp
python3 -m vendor_status_mcp.server --selftest # exercises every tool against live data
{
"mcpServers": {
"vendor-status": { "command": "python3", "args": ["-m", "vendor_status_mcp.server"], "cwd": "/path/to/vendor-status-mcp" }
}
}
Tools
| Tool | What it answers |
|---|---|
find_vendor | Resolve a name, slug or status-page domain to its map entry: status page URL, platform, whether a machine-readable feed exists, and its state in the newest poll. |
vendor_status | One vendor's state from the newest daily poll — ok / degraded / partial / major / maintenance / unknown — with the vendor's own status line, open-incident count and the poll timestamp. |
vendors_down_now | Every vendor that was not fully operational in the newest poll, worst first, plus counts by state across all 804 polled vendors. |
vendor_incidents | One vendor's incident history as its page posted it: title, state, impact, start/resolve times, latest update, link. Filter by date and state. |
vendor_resolution_times | Median, 90th percentile, over-24h count and the longest incident on record, from the vendor's own posted start and resolve timestamps. |
status_feed_urls | The summary JSON, incidents JSON, RSS and Atom endpoints for one vendor's page, by platform — so a script can poll it directly with no key. |
dataset_status | Vendors mapped, feeds readable, incidents on record and in the last 30 days, platform breakdown, cadence, license, bulk downloads. |
Every answer carries as_of / checked_at and source. The states come from
a daily poll, and every status answer says so in a caveat field rather
than letting a model present yesterday's read as a live probe — when you need
live, status_feed_urls hands you the vendor's own JSON. Where a vendor name
is ambiguous (gitlab when only gitlabhost is in the map) the answer says
"match": "fuzzy" and names the runner-up instead of guessing silently.
Why an MCP server and not just the JSON
The JSON is right there and it is free — take it. This exists for the case where a model needs one specific answer: the map is 160 KB and each vendor's history is another file, so the tools do the lookup, the filtering and the percentile arithmetic locally and an agent spends a few hundred tokens instead of a context window.
The map is the part you cannot get from any one vendor. Nobody publishes "here
is where every SaaS status page lives and which of them speak JSON" — it has to
be discovered, re-probed when pages move, and pruned when they die, every day.
find_vendor and status_feed_urls are that map, and the daily rebuild is
what keeps them true.
Caching and network
Tools read the free public Vendor Status Watch endpoints over HTTPS and cache
them on disk (~/.cache/vendor-status-mcp, override with
VENDOR_STATUS_MCP_CACHE) with ETag revalidation, so ten tool calls in a row
make at most one request per file per hour (VENDOR_STATUS_MCP_TTL, seconds).
If the network is down and a cached copy exists, the cached copy is served and
its own as_of tells you how old it is.
There is no key, no signup, no rate limit and no telemetry — this server sends nothing anywhere except plain GETs for public files.
Data, license, attribution
Data is compiled from vendors' own public status pages and released under CC BY 4.0 — credit "Vendor Status Watch" and link back. This server's code is MIT. Not affiliated with any vendor or status-page platform; each vendor's own page is the authority. "Resolution time" is the gap between a vendor's own posted start and resolve timestamps — not measured downtime, uptime or an SLA figure, and a vendor that posts every blip will look worse than one that posts nothing.
- Project repo, free Slack/Discord alert template: https://github.com/APVentureEngine/vendor-status-watch
- Raw HTTP API: https://approjects-vendor-status-watch.static.hf.space/api.html
- Hugging Face (CSV): https://huggingface.co/datasets/APProjects/saas-vendor-status-pages-outages-incidents-daily
The one paid thing
Everything above is free and stays free, and so is the GitHub Actions template that alerts your Slack or Discord when a vendor you depend on breaks. If you would rather not run Actions yourself, the same alerts as a hosted service are $49 for 12 months, with a free 30-day trial and no card. It is the only thing here that costs money.
Bugs, a vendor missing from the map, a tool you want: open an issue.