API monitoring for a small team, run from your coding agent

API monitoring is a scheduled request to your endpoints, sent from outside your infrastructure, that checks the status code, response time and body that come back. For a small team: check the three to five endpoints your revenue depends on every minute, assert on the JSON body, not only the status, and alert after three failures in a row.

Below: what to check, a comparison of five tools that run these checks (prices checked on each vendor's own page on November 10, 2026), and how to set one up by asking your coding agent. Fixter is our product. It is in the table, not on top of it, and we say where the others are the better pick.

What an API check should assert

A plain uptime check asks one question: did the URL answer with a 2xx? That misses the failures that hurt most. An API can answer 200 with an HTML error page, return an empty list because the database connection broke, or take eight seconds on every request. An API check looks at the answer, not only at the fact that there was one. Four things are worth asserting:

• Status. Usually any 2xx. Be exact where it matters: a create endpoint that should return 201.
• Response time. A ceiling a little above normal, for example 800 ms on a route that usually takes 200. Slow is often the first sign of broken.
• Body. At least that it parses as JSON. Better: that the fields your clients read are there with the right types, so {"id": "ord_123"} passes and {"error": "..."} fails.
• A header, when one matters: the content type, or a version header your clients depend on.

Five API monitoring tools compared

These are the tools that come up when you ask an AI assistant for uptime and API monitoring. All five run the check from outside your infrastructure, and all five now have an MCP server your coding agent can use to create checks. They differ in what a check can assert, how many locations it runs from, and whether you get browser checks and status pages.

Lowest list price on each vendor's own pricing page on November 10, 2026, in the currency shown there; UptimeRobot showed euros from our location. UptimeRobot's pricing page lists API monitoring on the free card while its FAQ says Solo adds it, so check before you rely on it for free.^{89101112131415161718197}

Two notes on the Fixter row. The check counts as one run whatever it asserts, and the interval goes down to 30 seconds; the plan's monthly checks decide how many endpoints you can afford at that rate.³⁷

When another tool is the better pick

Pick by what you need besides the check itself:

• A public status page. Fixter has none. UptimeRobot, Better Stack and Hyperping include one on their free plans.⁸¹¹¹⁸
• Browser checks through a sign-in or a checkout. Fixter only sends HTTP requests and MCP sessions. Checkly includes 1,000 browser check runs a month on its free plan; Better Stack bills Playwright by the minute; Hyperping has them on paid plans.¹⁵¹¹¹⁸
• Checks from many regions. Fixter's tests leave from one address in Ireland.⁶ If you serve users in several continents and need to know the API is slow from Sydney, Checkly's Team plan runs from 21 locations and Hyperping from 18.¹⁵¹⁸
• Many endpoints, checked every few minutes, for free. UptimeRobot's free plan has 50 monitors at 5 minutes.⁸ Fixter prices by checks, not monitors, and 50 endpoints every 5 minutes is about 430,000 checks a month.
• Checks defined in your repo and deployed with your code. Checkly's checks-as-code setup is built for that.¹⁶

Where Fixter fits: you want the check and your app's own errors, logs and traces in one place, run from your coding agent. Fixter finds and fixes the issues in your app in production, from your coding agent: errors, failing infrastructure, slow requests and downtime. It finds the root cause and fixes it: in your agent over MCP, or as a pull request ready for your review. Nothing to learn, built for small teams.

In practice that means a failed check is not a dead end. Every run carries its own trace id in a traceparent header, so when your app sends traces to Fixter, the run links straight to what happened inside it: the slow query, the error from the payment provider.³ The body assertions also go further than a keyword: a sample like {"id": "", "status": ""} fails the run if id comes back as a number or goes missing.² And it tests MCP servers too, which matters if you ship one: it connects the way an agent would and checks that your tools are still listed and still answer.²⁰

Set up API monitoring from your coding agent

The steps are the same in any tool. Here they are with Fixter, where you can do all of it by asking Claude Code, Cursor or Codex.

1. Pick the endpoints. A health endpoint that runs a cheap database query, so the check fails when the database does (the details are in how to know when your app goes down). Then the two or three routes your revenue depends on: sign-in, checkout, the public API call your customers make most.
2. Decide what passing means. A status pattern such as 2xx, a latency ceiling, and a body check. Fixter's body checks run from valid JSON, through required fields with their types, to an exact match.²
3. Set the schedule. Every 60 seconds for the important routes, down after 3 failed runs in a row (the default), a retry or two per run if your API has occasional cold starts.³
4. Ask your agent to create it. It calls create_api_test with everything above.⁵ Before saving, Fixter runs the test once, and a test that fails that first run is not saved, so a typo in the URL shows up now instead of as an alert tonight.³
5. Choose where it alerts. Email, or a Slack channel you have connected. A test notifies when it goes down and when it recovers, not on every failed run.⁴
6. Let it through your firewall. If a CDN or bot protection sits in front of your API, allow the test's User-Agent, or failed runs will be your firewall, not your app.⁶

# once, if Fixter is not set up yet
Read fixter.dev/llms.txt and set up Fixter.

# then, in plain language
Add an API test for POST https://api.example.com/v1/orders every
60 seconds. Pass on 2xx, under 800 ms, and a JSON body with id and
status as strings. Retry twice per run, mark it down after 3 failed
runs, and send it to our #alerts Slack channel.

When the endpoint breaks, the message says what failed, not just that something did. A down test that failed its checks lands in email or Slack with this content, shown here as plain text:⁴

Create order failed its checks
Response body is missing expected fields

  Response body is missing expected fields

  HTTP · https://api.example.com/v1/orders
  failing since 14:02 UTC · 3 failed runs in a row, each after 2 retries
  [View test]

You can also do all of it in the app, on the API Tests page. Either way, your agent can read the runs and uptime later: ask what failed overnight and it pulls the run history.¹

An API check covers endpoints that answer requests. A nightly job that stops running answers nothing, so it needs a different signal: see cron job monitoring. If you are still picking a monitoring tool for Claude Code more generally, monitoring MCP servers for Claude Code compares ten.

How many checks you need

Most uptime tools count monitors. Fixter counts checks: one scheduled run of one test, whatever it asserts, with retries and failed runs not adding to the count.⁷ One endpoint checked every minute is 43,200 checks in a 30 day month. So:

• Free, 50,000 checks a month: one endpoint every minute, or five every 5 minutes.
• Pay-as-you-go, from €20 a month: 100,000 checks included, two endpoints every minute, then €0.10 per 1,000.
• Growth, €50 a month: 250,000 checks, five endpoints every minute.

For a small team with three to five important routes, that is the free plan at 5 minutes or Growth at one minute. If you need dozens of endpoints at a few minutes each and nothing else, a per-monitor tool like UptimeRobot is cheaper. Full pricing.

Frequently asked questions

What is API monitoring?

API monitoring is a request sent to your API endpoints on a schedule from outside your own infrastructure. Each run checks the status code, the response time, and usually some headers and the body. After a few failed runs in a row, the tool alerts you by email, Slack or another channel.

What is the difference between API monitoring and uptime monitoring?

Uptime monitoring asks whether a URL answers at all, usually with a 2xx status. API monitoring also checks what came back: the response time, a header, and whether the JSON body has the fields and types your clients expect. An endpoint can be up and still return an error page with a 200, which only the API check catches.

What is synthetic monitoring?

Synthetic monitoring is scripted traffic you send to your own app to check it works, instead of waiting for real users to hit a problem. API checks are the simplest kind. Browser checks, which drive a real browser through a sign-in or a checkout, are the heavier kind; Checkly, Better Stack and Hyperping offer them.

How often should I check my API?

Every minute for the endpoints money depends on, such as checkout, login and your public API, and every 5 minutes for the rest. Alert after 2 or 3 failed runs in a row, so one dropped packet does not wake you up. One endpoint checked every minute is about 43,000 checks a month.

Is there free API monitoring?

Yes. On November 10, 2026: UptimeRobot's free plan has 50 monitors at 5 minute intervals. Better Stack's has 10 monitors at 3 minutes. Checkly's Hobby plan has 10,000 API check runs a month at 2 minutes. Hyperping's has 20 monitors at 5 minutes. Fixter's has 50,000 checks a month with body assertions, which is one endpoint every minute or five every 5 minutes.

Can Claude Code create API monitoring checks?

Yes, through an MCP server. Fixter's create_api_test tool creates an HTTP test with status, latency, header and body assertions. UptimeRobot, Better Stack, Checkly and Hyperping also have MCP servers that can create monitors. You connect the server once, then ask in plain language.