An API response-time SLA needs two numbers: a latency threshold and the percentage of requests that must meet it. “99% of requests under 200 ms” is measurable. “The API should be fast” is not.
Availability and response time are separate signals. A request can return 200 OK and still violate its latency target. A useful monitoring setup records both the outcome and duration of every synthetic check.
A response-time objective you can calculate
For a set of measurements:
compliance = requests at or below the threshold / all measured requests × 100If 9,940 of 10,000 requests finish within 200 ms, compliance is 99.4%. That passes a 99% objective but fails a 99.9% objective. Test your own sample with the API response time SLA calculator.
Define the measurement method too: observer location, request path, HTTP method, timeout, authentication, check frequency and evaluation window. Changing any of them changes the result.
Why P50, P95 and P99 still matter
Compliance gives a pass/fail result. Percentiles explain the distribution:
- P50 is the typical response.
- P95 is a practical view of the slow tail.
- P99 exposes the experience of the slowest 1%.
An API can pass “99% under 500 ms” while its normal response time gradually doubles from 80 ms to 160 ms. It still passes, but the regression is real. This is why a fixed SLA threshold and a learned baseline answer different questions.
A monitoring policy that avoids noise
Use a fixed per-monitor threshold when a contract or product requirement defines one. Otherwise, learn the service’s normal latency and alert on sustained deviation. Never open an incident from one slow sample: confirm the condition across consecutive checks or a sustained window.
Warden records response time on each check, learns P50 and P95 per monitor, and computes a default degraded threshold from that baseline. An explicit monitor threshold takes precedence. Degraded means reachable but abnormally slow; down remains a separate state.
What to put in the SLA document
Write down:
- The endpoint and request configuration.
- The threshold and required compliance.
- The evaluation window.
- Whether planned maintenance is excluded.
- Where the observer runs.
- How timeouts and failed requests count.
- The evidence retained for disputes.
That final point matters. A monthly percentage without check history is difficult to audit. Keep the measurements, incident boundaries and configuration that produced the number.
Start with one important endpoint
Choose a health or read-only API endpoint that represents real dependencies. Monitor availability and latency every 30–60 seconds, then review the first week of data before setting a tight threshold. If you already have a contractual target, configure it immediately and compare it with the observed P95.
The goal is not the most aggressive number. It is a stable definition that detects a user-visible regression early and produces evidence your team can trust.