Death by rounding
A service that responds in 3ms and a service that responds in 9ms both report "single-digit milliseconds" on most dashboards, and often both round to the same bucket. But one of them just got three times slower. Chain five services like that in a request path and the user-facing budget is gone, with every individual dashboard still green.
Precision as an early-warning system
Our API studio records timing at microsecond precision, a thousand times finer than millisecond displays, across REST, GraphQL, gRPC, and SOAP. At that resolution, drift is visible while it is still one bad query or one chatty serializer, not an incident. Paired with per-request P50/P95/P99, "it feels slower lately" becomes a chart with a date on it, which is the difference between a hunch and a ticket.
Do this with your own APIs
- Pick your five most-called endpoints and baseline their P95 this week.
- Alert on relative drift (say +50% from baseline), not only absolute thresholds.
- Chart 30 days of history before and after each release, because regressions cluster around deploys.
How we measured this
- Timings are captured with the runtime high-resolution timer (process.hrtime.bigint, nanosecond resolution) at request start, first byte and end, and reported in microseconds.
- P50, P95 and P99 are computed over the samples retained for a request. A single run shows its own timing, not a percentile.