How to Monitor the Uptime of AI Agents and MCP Servers

To monitor an AI agent or an MCP server, run a scheduled HTTP check against a real endpoint. Test the full path: network, authentication, and a simple tool call. Then track latency and error rate, because a server that answers with an error is not "up" in any useful sense.

A plain "is port 443 open" check is not enough. The process can run while the model provider, the database, or the login layer is broken.

Why AI endpoints need more than a ping

A normal web page is either served or not. An AI agent has more moving parts. It depends on a language model API, on tools, on secrets, and often on a queue.

Any one of these can fail while the front door still returns HTTP 200. For example, an agent can answer every request with a polite error message and a 200 status code. A simple uptime check will call that healthy.

So you need checks at three levels:

• Reachability: does the endpoint accept a connection and return a response?
• Correctness: does the response contain what you expect?
• Quality of service: is the response fast enough and rare enough to fail?

What an MCP server exposes

The Model Context Protocol (MCP) lets an AI client call tools on a server. Many servers use the HTTP transport. Messages are JSON-RPC requests sent with HTTP POST.

This gives you two cheap probes:

• The initialize request, which starts a session.
• The tools/list request, which returns the tools the server offers.

Check the exact request format against the MCP specification and against your server's own documentation. Transports and versions change, so do not copy a request from an old blog post, including this one.

Step 1: Check the endpoint over HTTP

Start with the simplest probe and add detail in steps.

1. Create a monitor for the public URL of the agent or MCP server.
2. Use the same HTTP method your clients use. For MCP over HTTP this is usually POST.
3. Send a small, valid request body. Do not send an empty request.
4. Set the expected status code, for example 200.
5. Add a body check, for example that the response contains the name of a known tool.

The body check is the most useful part. It proves the server parsed your request and did real work. A status code alone does not prove this.

Step 2: Test authentication

Most agent endpoints need a token or an API key. Auth breaks often, and it breaks quietly.

Create a dedicated test credential for monitoring. Give it the smallest rights possible, ideally read-only. Do not reuse a key from a real customer or a developer.

Run two checks:

• Valid credential: expect success. If this fails, your login layer or key store is down, or the key expired.
• No credential: expect a 401 or 403. If this returns 200, you have a security problem, not an uptime problem.

Also put the expiry date of the test key in a calendar. Many "outages" are only expired keys.

Step 3: Measure latency

Users do not wait for slow agents. A slow answer is a partial outage.

Set two limits:

• A warning limit, where the check is slow but works.
• A failure limit, where the check counts as down. This should be your client timeout.

Language model calls vary a lot in duration. For this reason, do not run your latency check through the model itself unless you want to test the model. Probe a light endpoint, such as tools/list or a health route, for uptime. Use a separate, less frequent check for a full model round trip.

Look at trends, not single values. Compare the median and the slowest requests over a week. When the slow end grows, you have a problem before users complain.

Step 4: Track the error rate

Synthetic checks tell you the state at one moment. Real traffic tells you what users see. Log every request from your own agent code and count the outcomes.

Useful error classes:

• HTTP 4xx from your own server, which often means bad requests or auth problems.
• HTTP 5xx from your own server.
• Upstream errors from the model provider, such as rate limits (HTTP 429) or server errors.
• Tool errors, where a tool call fails inside an otherwise normal answer.
• Timeouts.

Alert on the rate over a window, not on one error. For example, alert when errors stay above a set share of requests for several minutes. Choose the numbers from your own normal traffic. There is no universal "good" value.

Step 5: Add heartbeats for background agents

Some agents do not have a public URL. They run on a schedule, or they read from a queue.

Use a heartbeat (also called a dead man's switch) for these. The job sends a small ping to a monitoring URL after each successful run. If the ping does not arrive on time, you get an alert.

Send the ping only after the job really finished its work. A ping at the start of the job proves nothing.

Choose a tool and set up alerts

Any uptime tool that supports custom HTTP methods, request bodies, headers, and body checks can do this work. Uptrack (from the 2folk team) is one option among others. Compare tools on those features, not on the number of checks.

Whatever you pick, send alerts to a channel your team actually reads. Use at least two channels, for example email plus chat. Test the alert path once a quarter.

A short checklist

• One monitor for the public endpoint, with a body check.
• One monitor for authentication with a valid test credential.
• One check that unauthenticated calls are rejected.
• Latency warning and failure limits.
• Error-rate tracking from real traffic.
• A heartbeat for each background job.
• Alerts to two channels, tested.

Frequently asked questions

How often should I check an MCP server?

Check a light endpoint every one to five minutes. Run a full tool call less often, for example every 15 minutes, to limit cost and load. Pick the interval from how fast you must know about an outage.

Can I use a normal uptime tool for an AI agent?

Yes, if it can send a POST request with a body and headers, and check the response text. A tool that only checks for HTTP 200 on a GET request will miss most real failures.

Should monitoring calls go to the real language model?

Do this sparingly. Each model call costs money and adds load. Check the model path with a rare, short test call, and use light endpoints for frequent checks.

What should I do when the model provider is down?

Your own server is fine, but the feature is not. Show a clear message to users, and use a fallback such as a cached answer or a human hand-off. Then report the status on your status page.