An API health check is an automated request that confirms an endpoint is reachable and returning what it should. Paste a public HTTPS URL below to run one now: you get the status code, the response time, the content type and the body. A complete check verifies the body too, because a service can answer 200 while the data behind it is missing or wrong.
What a health check should actually verify
Most monitoring stops at the status code, which is the least informative signal your API produces. An endpoint that answers 200 OK with {"items": []} when it should return twelve items is broken, and every ping-based monitor on the market will report it as healthy.
A health check worth running verifies three things: that the endpoint responds, that it responds fast enough, and that the shape of what it returns still matches what your application expects.
Reading the response above
- Status — anything in the 4xx or 5xx range is an outright failure. A 3xx means you were redirected, and the final URL is shown.
- Latency — measured from our servers. Compare it over time rather than in absolute terms, a jump from 120 ms to 900 ms matters more than either number alone.
- Body — the part that tells you whether the answer is correct. Read it, not just the code above it.
From a one-off test to a real check
Once you know what a healthy response looks like, describe it once and let it be verified continuously. In Safeship that means a status range, a response time ceiling and a JSON schema for the body. When reality stops matching, you get an alert containing the actual response, so you can tell a transient blip from a regression without opening anything.
If you work in Claude Code or Cursor, the Safeship MCP server does the setup for you: it reads the endpoint, infers what a valid response looks like and creates the check.
Common questions
- What is an API health check?
- A periodic automated request to an endpoint that confirms the service is reachable and answering correctly. The minimal version asks for a status code. The useful version also inspects the response body and the latency, because a service can return 200 while its database is unreachable.
- What is an HTTP health check?
- The same idea carried over HTTP: a client requests a known URL, usually /health or /healthz, and treats a 2xx response as healthy. Load balancers and orchestrators use it to decide whether to keep sending traffic to an instance.
- How do you create a health check API?
- Expose a route such as GET /health that returns 200 with a small JSON body. Have it verify the dependencies the service cannot work without, typically the database and any critical upstream API, and return a non-2xx status when one of them fails. Keep it fast and unauthenticated, and do not have it hit anything that would be expensive under a per-second poll.
- What should a health check endpoint return?
- A status code that reflects real health, and a body naming each dependency and its state. Returning 200 with a body that says the database is down is the most common mistake: whatever polls the endpoint reads the code, not the prose.
- Why is checking the status code not enough?
- Because the failure that hurts is the one where the server answers correctly and the data is wrong. A migration dropped a column, an upstream renamed a field, a cache is serving an empty list. The status stays 200 throughout, and a ping-based monitor reports everything is fine.
- Does this tool support POST requests or auth headers?
- No. It sends a GET to a public HTTPS endpoint, with no headers and no body, so it cannot be used as a relay into private networks. Authenticated and non-GET checks are part of an account.
- How often should an API be checked?
- Match the interval to what an outage costs. Every minute for anything a customer touches, every five to fifteen minutes for internal services, hourly for batch endpoints. Polling faster than your alert response time only adds noise.