Cloud & APIs
API observability that earns its keep
Four API signals that show whether the product is working before customers report a problem.
Written by
Daniel Okafor
Head of Platform
Key points
- Measure user-facing success per endpoint. The raw HTTP 200 rate hides failures.
- Compare latency at the edge with latency at the service boundary to find internal delay.
- Every dependency needs a saturation signal, a named owner, and a cost per successful request.
Most teams have plenty of dashboards and little observability. There are graphs, alerts, and a monthly bill, but nobody can answer the question that matters during an incident: is the product working for the people who pay for it?
An API needs four signals that map to that question. Everything else is supporting evidence.
One: the user-facing success rate
Track the rate at which a request achieved its business purpose. A 200 with an empty result set can be a failure. A 409 can be a perfectly healthy idempotency response. Define success per endpoint and measure it at the edge.
This single change usually removes half the noise from the on-call rotation, because it stops paging on the wrong things.
Two: latency at the boundary
Measure p50, p95, and p99 at the edge, and again at the service boundary. The difference between the two is time spent in your own infrastructure. If it grows, you have a queue, a lock, or a dependency you have not noticed.
Report the numbers on the same axis as traffic. A p99 that only degrades at 3am is a different problem from one that degrades at 9am.
Three: saturation with a named owner
Every dependency needs a saturation signal and a person. Connection pools, queue depth, cache hit rate, database write latency, third-party rate-limit headroom. A metric without an owner becomes a decoration.
We put the owner in the runbook. When the alert fires at 2am, the on-call engineer should know whose system is at the other end of the line.
Four: cost per successful request
Cloud bills are lagging indicators. Cost per successful request is a leading one. When it moves without a corresponding move in traffic, something in the architecture changed: a cache expired, a query plan flipped, a retry loop started.
Put it next to the success rate. The two numbers together tell you whether you are buying reliability or just buying compute.
Keep the rest, but keep it quiet
Traces, logs, and profiles are essential for diagnosis. They are not the first thing an operator should see. Route them to the incident, link them from the four signals, and sample them aggressively enough that the bill does not become its own incident.
Observability is a small set of questions you agree to answer, instrumented so that answering them is faster than arguing about them.
FAQ
Common questions.
What are the four API observability signals?
The four are user-facing success rate, latency at the edge and service boundary, saturation with a named owner, and cost per successful request. Together they show whether the product is working, where delay lives, which dependency is constrained, and what reliability costs.
Why does HTTP 200 fail as a success metric?
A 200 response can still return an empty result, stale data, or a business failure. Success should be defined per endpoint as the request achieving its business purpose, measured at the edge where the customer experiences it.
How do you measure API cost per successful request?
Divide the relevant infrastructure and dependency cost for a period by the number of requests that achieved their business purpose in that period. Track it beside traffic and success rate so architectural regressions show up before the cloud bill does.
Keep reading
All postsEngineering
Why we still choose Angular for enterprise platforms
Why we still choose Angular for long-lived enterprise platforms, and what we look for before committing to a framework for years.
Commerce
The real cost of a slow checkout
How small checkout delays turn into lost revenue, and the four numbers we track before changing the design.