Skip to content
upcertain

Guide

How to monitor your MCP server's uptime

If customers connect Claude, ChatGPT or Cursor to your product over the Model Context Protocol, your MCP server is production infrastructure. When it is down, their agents silently lose access.

Updated 25 October 2026 · By the Upcertain team

What to monitor

  • The MCP endpoint, for example https://api.example.com/mcp, which clients connect to over HTTP.
  • The sign-in pieces, if you use OAuth: the authorisation server metadata and the token endpoint.
  • The certificate, because clients refuse invalid ones without telling the user much.
  • The services behind the tools, which are usually your existing API.

Expect a 401

A remote MCP server that requires sign-in answers an unauthenticated request with HTTP 401 and a WWW-Authenticate header that tells the client where to sign in. That 401 is the healthy answer. Monitor the endpoint with an HTTP check whose expected status is 401: a 401 means up and still protected, while a 5xx or a timeout means down. A 200 means authentication has been switched off, which you also want to know.

URL: https://api.example.com/mcp
Method: GET
Expected status: 401
Interval: 1 min
Confirmation: 1 check after 15 s

Check the sign-in metadata

OAuth-based MCP clients first fetch metadata documents to find your authorisation server. Add a keyword monitor on the protected-resource metadata URL that must contain your issuer address, for example "authorization_servers". If that document breaks, new users cannot connect even though the endpoint answers.

URL: https://api.example.com/.well-known/oauth-protected-resource
Mode: must contain
Keyword: "authorization_servers"

Going deeper than reachability

An endpoint that answers 401 can still have broken tools. For a deeper check, expose a small health endpoint that exercises what the tools depend on (the database, the upstream API) and monitor it over HTTP with a keyword. Keep it free of customer data.

Alerting and communicating

  • Route MCP alerts to the team that owns the API, since the cause is usually there.
  • Put the MCP server on your status page as its own service, so customers whose agents stopped working can see why.
  • Watch your certificate: SSL monitoring warns weeks before expiry.

The other direction

Monitoring works the other way round as well. Upcertain has its own MCP server, so Claude or Cursor can ask which monitors are down and read incidents, including those of your MCP server.

Questions

Can I monitor an MCP server that runs locally over stdio?
No. Local stdio servers run inside the client on the user's machine and have no address to check. Uptime monitoring applies to remote MCP servers reached over HTTP.
Should the monitor sign in to the MCP server?
Usually not. Checking that the endpoint answers 401 and that the sign-in metadata is served covers reachability without storing a long-lived token in the monitor. For a deeper check, monitor a separate health endpoint.
How often should an MCP endpoint be checked?
As often as the API behind it, because agents depend on both. If agents use your product during working hours, every 30 seconds to 1 minute keeps detection within about a minute.

Related