When an API breaks, its consumers know within one request. Whether you know depends entirely on what you were watching. Here is what to watch.
Detecting API failures before customers means monitoring each critical endpoint individually — availability, status codes, latency percentiles against a measured baseline, and timeout rate — and alerting on confirmed failures and significant deviations rather than waiting for a hard outage. APIs rarely die suddenly. They degrade: p95 latency climbs, a trickle of 5xx starts on one route, timeouts creep upward as a pool saturates. Each stage is measurable from the outside, which means the difference between finding out from your monitoring and finding out from an angry integration partner is mostly a matter of instrumentation choices.
/health says nothing about /orders.When a page breaks, one user has a bad session. When an API breaks, every consumer built on it breaks simultaneously — customer integrations, mobile apps, partner systems, your own frontend. The blast radius is multiplied by everything downstream, and so is the reputational cost: an integration partner who got paged because of your API remembers it at renewal time.
API consumers are also unforgiving reporters. Humans retry and shrug; software retries on a schedule, fails its own SLAs, and generates support escalations with timestamps attached. There is no ambiguity about when your API went bad — their logs have it to the second. The only open question is whether your monitoring had it first.
Hard failures — the API fully down — are the minority and the easy case; any uptime check catches them. The common sequence is gradual, and each stage is independently detectable:
Detection at stage 1–2 is a warning to investigate; at stage 3 it is an incident; at stage 4 it is public. The entire value of API monitoring design is moving detection leftward in that sequence.
Choose the endpoints that map to money and core journeys — auth, the main reads, the writes that matter, checkout — and give each:
Fixed latency thresholds fail the fairness test across a real API surface. 400ms is an emergency for the autocomplete endpoint and a Tuesday for the report generator. Set the threshold loose enough for the slow endpoint and the fast one can triple silently; tight enough for the fast one and the slow one pages daily. The escape is per-endpoint baselines:
Error rates get the same treatment: most endpoints' baseline error rate rounds to zero, so a floor matters (two failures in an hour is a pattern; one is weather), and the comparison is always against this endpoint's history, not the fleet average.
Detection is only half the mean-time-to-recovery equation. The handoff matters:
| Monitor granularity | Per endpoint — the endpoints mapping to money and core user journeys |
|---|---|
| The failure sequence | Latency drift → timeout onset → 5xx trickle → saturation ("the outage") |
| Most predictive metric | Timeout rate — requests stalling inside the service signal resource exhaustion |
| Baseline rule | Alert at ratio + absolute deviation from the endpoint's own p95 (e.g. ≥1.8× and ≥150ms) |
| Confirmation | Two consecutive failed checks before an incident — single blips are network weather |
| Worst failure mode | HTTP 200 with a wrong body — caught only by content assertions |
| Check interval | 1–5 minutes outside-in; 1 minute where a strict SLA applies |
API monitoring sends requests to each critical endpoint on a fixed interval from outside your infrastructure, validates the response status and optionally its content, records latency, and tracks failures. Failures are confirmed across consecutive checks before an incident is raised, and latency is compared against the endpoint's own measured baseline so degradation is caught before hard failure.
Health endpoints typically return a static success without exercising the database, dependencies or business logic, so they stay green through most real failures. Meaningful API monitoring checks the endpoints consumers actually call, with the assertions those calls depend on.
Latency percentile drift against the endpoint's own baseline is the earliest signal — p95 rises before errors appear. Timeout rate is the most predictive of imminent failure, because timeouts mean requests are stalling inside the service, the external signature of pool or queue exhaustion. Error-rate deviation, especially any 5xx on a normally clean endpoint, is the confirmation.
Record response time on every check and keep percentiles per endpoint — p50 for the typical case, p95 for the degradation-sensitive tail. Compare current values against a trailing baseline (one to two weeks) and alert when deviation is both proportionally and absolutely significant. Averages alone hide tail degradation; fixed thresholds cannot be fair to endpoints with different natural speeds.
Common causes include resource exhaustion (connection pools, memory, worker queues) building up gradually, database performance degrading as data grows, downstream dependency failures propagating upward, expired TLS certificates, DNS misconfiguration, and regressions shipped in deployments. Most give measurable warning — latency drift, timeout onset, error trickles — before becoming outages, which is what per-endpoint baseline monitoring is designed to catch.
Yes, for critical endpoints. Status-only checks miss the failure mode where an API returns 200 with a wrong, empty or stale body — often the most damaging failure because nothing anywhere signals an error. Asserting that a stable field or value exists in the response catches it from the outside.
Merik monitors APIs endpoint by endpoint, exactly on this model. Each registered endpoint gets outside-in checks with status validation and optional content assertions, two-failure confirmation, and latency recorded into its own 14-day p50/p95/p99 baseline. Failures are classified by stage — DNS, TLS, request, response — so the incident says where in the path it died, and timeout-shaped failures are distinguished from refusals.
Latency drift against baseline, error-rate deviation and budget burn feed early warnings with risk, confidence and the evidence list — the stage-1-and-2 detection this article argues for. When an incident does open, it arrives assigned to the endpoint's owner with recent deploys correlated on the timeline, alerts exactly once, and the stored checks roll into monthly uptime and error-budget health for the SLA conversation later. Detection leftward, response pre-wired.
One route 500s, a pool saturates, a consumer dies — and the process stays healthy throughout.
If a human has to notice any of these ten, the monitoring has a gap.
Most incident time is spent not knowing. Six changes that cut detection from hours to minutes.