01 What this page answers #
Services and SLOs answer “is it healthy”. Usage answers “what is actually being used, and by whom” — the question behind capacity planning, deprecation decisions, and knowing which endpoint deserves the optimisation budget.
It is built from the same spans, but counted per request rather than aggregated into rollups, which is what lets it break traffic down by route, operation and user.
02 The panels #
- Summary tiles
- Requests, unique users, distinct pages, average and p95 latency, and error rate for the window.
- Traffic chart
- Requests, users and errors over time. The shape matters more than the numbers — a flat line where you expect a daily curve usually means an instrumentation problem, not a quiet day.
- Top pages
- Busiest
http.routevalues with hits, users, error rate and p95. - Top functions
- The same, by operation (
METHOD /route), which separates a read from a write on the same path. - Top users
- Busiest end users, when user identity is present.
Page and function tables export to CSV.
03 Getting user attribution #
If unique users reads 0, your instrumentation is not attributing requests to anyone. That is the default — OpenTelemetry does not guess who a user is.
Set an end-user attribute on the entry span, typically in the middleware that already resolves the authenticated principal:
# Python
from opentelemetry import trace
span = trace.get_current_span()
span.set_attribute("enduser.id", current_user.id)
// Node.js
const span = require('@opentelemetry/api').trace.getActiveSpan()
span?.setAttribute('enduser.id', req.user.id)
Whatever you set here is stored with the span and displayed in the UI. Use an internal user id or a hash. Email addresses and usernames turn your telemetry store into a personal-data store, with the retention and access obligations that implies.
04 Why the window stops at 7 days #
Usage counts individual requests, so it reads raw spans, and raw spans are kept for 7 days. Ranges are 3 hours, 24 hours, 3 days and 7 days.
Everything computed from rollups — service health, charts, SLO budgets, alert rules — is unaffected and looks back 90 days or a year. If you need long-run traffic trends, take them from a service's throughput chart rather than from this page.
05 Reading it well #
- High hits, low error rate, high p95 — the best optimisation target you will find: lots of people waiting, nothing broken.
- Low hits, high error rate — often a deprecated route that only a stale client still calls. Worth deleting rather than fixing.
- A route you do not recognise — usually a health probe, a scanner, or a client you forgot about. Worth knowing which.
- An exploding route list — concrete URLs are being sent as
http.routeinstead of templates. See Getting started.