Guide · Status pages
MCP server status page
A status page is the first URL your users hit when an agent stops responding. For an MCP server, that page has to answer one question in one line: is the protocol working right now? Everything else is context.
TL;DR
A good MCP status page shows current state (alive / degraded / down), the last 90 days of uptime as a tiny bar chart, response-latency percentiles, the current tool surface (count + last-changed timestamp), and a short incident log. Skip the aspirational 100% badges and the jargon. AliveMCP generates one automatically at status.yourdomain.com on the Team tier for $49/mo. Join the waitlist.
Why MCP needs its own status-page conventions
Status pages have 15 years of convention — Statuspage, Better Stack Status, Instatus, Atlassian's playbook. All of them assume a generic HTTP service: you check one or two endpoints, you render a green/yellow/red dot. That isn't enough for an MCP server. An MCP can be up at the HTTP layer and completely broken at the protocol or tool layer, and the people reading your status page are agents' operators, not humans refreshing the page. They need protocol-level truth, not marketing truth.
The useful mental model: an MCP status page is a thin public shell around your internal health-check probe. If the internal probe is lying, the status page will lie. That's why the probe has to run initialize and tools/list, not just a TCP connect.
What a good MCP status page shows
- Headline state, one sentence. "All systems operational" is fine if it's true. "Operational — tool surface unchanged in 48h" is more useful. Don't hide behind color alone.
- Uptime chart, 90 days. One row per service, one bar per day, green / amber / red. Render the exact minutes of downtime on hover. If you can't show 90 days, you haven't been monitoring long enough to earn the page.
- p50 and p95 latency. Last 24h and last 7d. Agents are latency-sensitive because their upstream model has a time budget — a slow MCP turns into a degraded agent long before it turns into an outage.
- Tool surface. Current count of tools, schema-hash short prefix, last-changed timestamp. This is the single most-requested thing we hear from integrators, and no legacy status page vendor shows it.
- Incident log. The last 5 incidents, with start / detection / mitigation / root-cause timestamps. No jargon. No "we're investigating" that stays up for three days.
- Contact path. A single link to report an issue. Not a ticket portal. Not "please raise with your account manager."
Mistakes we see on existing MCP status pages
- Status page that isn't monitored. A static HTML page that a human manually flips to "degraded." It'll be wrong every time, because humans sleep.
- Color without data. A green dot with no uptime chart, no latency, no tool-surface signal. Users can't verify your claim and learn to distrust the whole page.
- 100% everything, always. Nobody runs 100%. A too-clean history reads as fiction and you lose the benefit of the honest one you could have shown.
- Mixing marketing and ops. "Check out our new pricing!" banners on a status page are the clearest signal that the people running the page don't understand who reads it. Readers are in incident-mode — give them the numbers and get out of the way.
- No history on incidents. Post-mortem linked in the incident row beats "we'll update within 24h." It's public proof the team knows what happened.
Build vs buy for solo MCP authors
If you're an indie MCP author with one or two servers, the math is usually "buy." A self-hosted status page on Statuspage-like infrastructure costs $29+/mo plus a day of setup; the cheapest viable off-the-shelf has no MCP-aware signals, so you'd still build a custom probe and feed it in. Writing a static HTML page by hand, refreshed by a cron, gets you a functional status page in half a day — but no 90-day uptime, no latency percentiles, no schema-drift signal. You end up rebuilding the thing you tried to avoid.
At $49/mo, the AliveMCP Team tier gives you a status page on status.yourdomain.com (CNAME) that reads from the exact same probe that powers the public AliveMCP dashboard: initialize + tools/list every 60 seconds, p50 + p95, tool-surface hash, and 90-day uptime. Incident log is manual (we don't auto-write drama); the data fields are automatic.
How status.yourdomain.com works on AliveMCP Team
Add a CNAME from status.yourdomain.com to status.alivemcp.com. We provision a TLS cert automatically (Caddy on-demand issuance) and serve the status page with your branding. Add up to 10 monitors per account. Integrate incident posts over the Author tier webhook if you want them programmatic. The public dashboard continues to show your public endpoints free; the status-page subdomain is the customer-facing cleaned-up version.
Related questions
Can I use Statuspage or Instatus instead?
Yes — both will render a status page if you feed them component states. You'll still need the MCP-aware probe we describe in the health-check reference; the legacy vendors aren't protocol-aware.
Should the status page auto-open incidents on a failed probe?
On the first failed probe, no — one bad probe is almost always a network blip. On three consecutive failures in 3 minutes, yes. That threshold is AliveMCP's default and can be tightened on request.
What's the SEO angle on having a status page?
Secondary but real. Users searching "is X MCP down" will land on it, and an incident-log with real post-mortems earns links from other MCP authors who reference your write-up. Don't optimize aggressively — the status page's primary job is incident communication, not ranking.