MCP server uptime badge

Why a badge matters for MCP authors

GitHub is where most MCP server discovery happens. A developer evaluating whether to integrate your server will look at your README before they look at your docs. A badge that shows "99.8% uptime — live" communicates three things without a word of copy:

1. The server is working right now.
2. Somebody is monitoring it, which means somebody cares about keeping it up.
3. There's a public status page they can check if something breaks.

The inverse is also true. A missing badge — combined with the knowledge that most public MCP servers are abandoned — makes an evaluator wonder whether the server is still maintained. It's an opportunity to build trust that most MCP authors leave on the table.

What the badge shows

• Current status indicator — green (last probe succeeded), yellow (degraded — responding but with errors or high latency), or red (down — last 3 consecutive probes failed).
• 30-day uptime percentage — calculated from the full probe history for the trailing 30 days. Shows as a number like "99.7%" next to the status color.
• Response time — the median response time from the last 24 hours, shown as a secondary label for integrators who care about latency.

The badge is an SVG served with a short Cache-Control: max-age=60 header, so it reflects the latest probe result within a minute of any status change.

Embedding in a GitHub README

Once you've claimed your server listing on the Author tier, your badge embed snippet looks like:

[![MCP server status](https://alivemcp.com/badge/your-server-slug.svg)](https://alivemcp.com/status/your-server-slug)

This is standard Markdown image-with-link syntax. The badge links to your public status page where visitors can see the full probe history. Replace your-server-slug with the slug shown in your AliveMCP dashboard.

For an HTML page or docs site:

<a href="https://alivemcp.com/status/your-server-slug">
  <img src="https://alivemcp.com/badge/your-server-slug.svg"
       alt="MCP server status" height="20">
</a>

Badge behavior during incidents

The badge reflects the 3-consecutive-probe confirmation threshold — the same threshold used for alerts. This means:

• A single failed probe does not turn the badge red. It turns yellow (degraded) for the duration of the confirmation window.
• The badge turns red only after three consecutive failures (3 minutes at 60-second cadence). This prevents your README from showing a red badge for transient network blips.
• Recovery is symmetric: the badge turns green again after three consecutive successful probes following a red state. This prevents premature "all clear" on a flapping server.

Other places to embed the badge

• Your MCP server's npm or PyPI package page — both allow Markdown in the README, so the same snippet works.
• Your personal developer site or portfolio — if you maintain multiple MCPs, showing a live status grid for all of them signals professionalism.
• Your server's documentation site — a badge in the header or sidebar means users always know the current status without leaving the docs.
• The MCP.so and Smithery registry listings — once these registries support embedded metadata, a verified-live badge from AliveMCP will be part of the verified-author certification.

Getting your badge

The badge is part of the Author tier ($9/mo). Author tier also includes custom alert webhook configuration, 90-day probe history with full resolution, and the verified-author badge on public registry listings. The public tier (free) shows your server's status on the live dashboard but does not include the badge embed API or custom alerts. Compare all plans or join the waitlist to get the Author tier at launch.

Get early access

Related questions

Further reading

• MCP server status page — building a public status page
• MCP server uptime API — embed uptime data programmatically
• MCP server uptime monitoring — the full stack explained