URL Performance
Per-URL latency table grouped by full request URL with avg, p50, p95, max and error count so you can pinpoint slow pages and endpoints.
URL Performance is a per-URL latency table that groups requests by their full HTTP URL (not by logical operation name). It complements the Operations card (API Latency) — operations aggregate by operation (GET /users/:id), URLs aggregate by what the user's browser actually fetched (/users/4710). Use this when you need to know which specific pages are slow, not just which routes.
Use Operations when looking at backend routes (parameterised paths). Use URL Performance when looking at per-page client-side calls or when you don't have a route template at all (e.g. static assets, third-party calls).
What the Data Contains#
Each row has:
| Column | Description |
|---|---|
| method | HTTP method (GET, POST, PUT, PATCH, DELETE…) |
| url | The full request URL |
| request_count | Total request count for this URL in the selected time range |
| avg_duration | Mean duration (ms) — coarse but useful when paired with p95 |
| p50 | Median — what a typical user experienced |
| p95 | Slow tail — the 5% slowest. Most user-facing pain lives here |
| max_duration | The single slowest request in the window — outlier detection |
| error_count | Number of responses with HTTP status 400 or higher |
Rows are sorted by p95 descending — the slowest tails surface to the top.
URL vs Operation Explained#
The distinction matters when reading the table:
- Operation is a logical route template —
GET /api/users/:idis one row in Operations regardless of which user ID was hit. - URL is the literal string the SDK saw —
https://api.example.com/users/4710and/users/4711are two different rows here.
If your backend has high-cardinality URLs (every user ID is its own row), URL Performance can get noisy fast. That's by design — it tells you which specific users / records / pages are slow. For aggregate route-level monitoring, prefer Operations.
Common Patterns to Watch#
A single hot URL with p95 well above the rest is usually a specific record causing an N+1 query or a hot row
If GET /users/4710, /users/4711, /users/4712 all show up slow, the route itself is slow — drop to the Operations card
One catastrophic request hidden in healthy traffic — usually a runaway query or a rare cache miss. Worth tracing
If .js / .css / .png URLs show high p95, your CDN cache hit rate is dropping. Check origin shielding
Best Practices#
Operations answers "is this route slow on average?" URL Performance answers "which specific request was the slowest?"
If every user ID is its own URL the table gets long. When you report spans yourself, give them a route-template operation name (e.g. GET /users/:id) so Operations aggregates them — http_url still keeps the raw path
Look up a slow URL in the Failed requests card to see specific failure cases
A single Max of 8+ seconds is worth tracing in detail — often surfaces a bug that p95 alone would miss
A URL with 10,000 requests at 300ms p95 affects users more than one at 50 requests with 1.5s p95. Both matter — weigh by reach