Start with a health endpoint
A health endpoint should be fast, safe, and explicit. It should not expose secrets or full diagnostics, but it should tell the truth about dependencies that decide whether the API can serve customers.
GET /health
200 OK
{
"status": "ok",
"database": "ok",
"queue": "ok"
}
Monitor the routes customers actually use
Many APIs have a health endpoint that stays green while the most important route is broken. Add monitors for login or token exchange, the highest-volume read endpoint, and the route that directly creates revenue or operational work.
Webhook receivers are easy to miss
Payment events, delivery updates, messaging callbacks, and order integrations often arrive through webhooks. If a webhook route is down, the failure may not show up as a visible website outage. Monitor the receiver path so missed events are not discovered hours later in support tickets.
What to check
| Signal | Why it matters |
|---|---|
| Status code | Confirms the route returns a success response instead of a redirect, 404, or 500 class error. |
| Response time | Slow APIs can break integrations before they fully time out. |
| Expected content | Prevents a blank page, error HTML, or wrong JSON body from being counted as healthy. |
| SSL validity | Expired certificates can break clients even when the server process is running. |
Use TCP checks for supporting services
If the monitoring location can reach your database, queue, cache, or custom service port, TCP checks can help distinguish application failure from network reachability failure. Do not expose private ports to the public internet just to monitor them.