Metrics Reference
What every number in ApiTraffic measures, how it is derived, and what to look for.
Note: These are the same definitions shown in the app when you open the help on a number, so the two cannot disagree. 10 metrics.
Dashboard
What your API did in the selected period, and what needs attention regardless of it. The summary figures follow the period selector; the attention panel and the connected server count do not.
Requests (count)
How many requests your API served in the selected period.
How it is measured. Counted from the requests ApiTraffic observed, so it reflects what actually reached your instrumented application - not what a load balancer or CDN turned away first.
What to look for. The change against the previous period matters more than the number. A sharp drop with no deploy behind it is usually a reporting problem rather than a traffic one: check that your servers are still connected before assuming your traffic fell.
Average response time (ms)
The mean time your API took to respond during the period.
How it is measured. A straight average across every request in the window, fast and slow alike.
What to look for. Useful for spotting a shift, poor for judging user experience - an average is dragged down by the many fast requests and hides the few slow ones entirely. When this looks fine but people are complaining, read p95 instead. A rising average with a flat p95 means everything got slightly slower; a flat average with a rising p95 means a subset got much worse.
p95 latency (ms)
The response time 95 out of every 100 requests came in under.
How it is measured. A percentile over the requests in the period, not an average. Averages hide slow requests behind fast ones; p95 is the number that reflects what your least fortunate users actually experienced.
What to look for. Endpoints over 1000 ms at p95 are flagged, though the right budget differs per endpoint - a report that takes two seconds may be fine where a login is not. Compare against the same endpoint last week rather than against other endpoints, and check the dependency split before optimising code: if most of the time is spent waiting on a database or an outbound call, faster application code will not move it.
Error rate (percent)
The share of requests in the selected period that failed.
How it is measured. Failed requests divided by total requests. A request counts as failed on a 5xx response, or a 4xx your API returned where the route itself exists - so a genuine 404 on an unknown path is not counted against you.
What to look for. Above 1% is worth a look and above 5% is treated as critical, but the absolute figure matters less than the shape: a rate that steps up at a deploy is a regression, while one that drifts up over days is usually a dependency degrading. Check whether the failures concentrate on a few endpoints before assuming it is general.
Blocked by firewall (count)
Requests the firewall rejected before they reached your route handlers.
How it is measured. Counted from the decisions the firewall recorded on each matched request, across the whole period rather than from a sample.
What to look for. A steady background level is normal on any public API - most of it is automated scanning. What matters is a sudden change in shape: a spike concentrated on one endpoint is worth investigating, where a spike spread evenly is usually a scanner passing through. Zero blocks with a policy configured is worth checking too, since it often means the policy is in monitor mode rather than enforcing.
Would have been blocked (count)
Requests a monitor-mode policy scored high enough to reject, but let through.
How it is measured. The firewall evaluated these exactly as it would when enforcing, and recorded the decision without acting on it.
What to look for. The most actionable firewall number, because it is precisely what would change if you switched the policy to enforcing. These attacks reached your application. Review a sample to confirm the detections look right, then enforce - a monitor-mode policy left running indefinitely provides reporting and no protection.
Open drift findings (count)
Detected changes to your API that have not yet been reviewed.
How it is measured. Each endpoint learns a baseline from its own traffic; a drift finding is raised when live traffic stops matching it. Detection is observe-only and never blocks anything.
What to look for. Breaking changes are the ones to look at first - they mean a consumer that worked yesterday may not today. An alert explained by a deploy is usually intentional and can be closed quickly. The ones worth real attention are unexplained changes with no deploy behind them, which often mean an upstream dependency changed under you.
Slow endpoints (count)
How many endpoints are over one second at p95.
How it is measured. Counts endpoints above 1000 ms at p95 that also served at least 20 requests in the period, so a single slow call on a rarely used route does not register.
What to look for. One second is a general budget, not a rule - a report endpoint taking two seconds may be entirely reasonable where a login taking one is not. Treat this as a list to triage rather than a count to drive to zero, and start with the endpoints carrying real traffic.
Servers connected (count)
How many of your application instances are reporting to ApiTraffic right now.
How it is measured. A live presence count rather than a figure for the selected period - it reflects this moment, so it does not change when you change the period.
What to look for. Zero with traffic still arriving usually means instances are sending data but not maintaining a live connection. Zero with no traffic means nothing is reporting at all, and every other number on this page is empty rather than healthy - which look identical otherwise. A count well below your deployed instances suggests some are running without the SDK configured.
Needs attention
Everything currently worth looking at across errors, latency, the firewall and drift, ranked by severity.
How it is measured. Evaluated continuously in the background against a fixed recent window - which is why it does not change when you change the period selector, unlike the rest of this page. Signals clear themselves automatically once the underlying problem stops.
What to look for. Critical items first; the panel opens itself when a new one arrives. Dismissing a signal hides it until it gets materially worse, so acknowledging something you already know about will not hide a genuine escalation of it later.