Application health
Slow is a real incident too, not just down or throwing
Controller/action latency and database queries, plus a full nested trace of the one request that was actually slow, correlated the same way an error spike already is.
Two panels, trending against themselves
Request performance shows p50/p95/p99 per transaction. Database shows a slow-query count (anything over 500ms) and its own p95, plus live connection-pool utilization, each panel trending against its own immediately preceding window, the same comparison an error-rate spike uses.
Each panel trending against its own immediately preceding window.
A full waterfall for the one request that was actually slow
Beyond the aggregate panels, a captured trace shows one specific request's own nested call tree: the controller action, any service-layer code wrapped by hand, database queries, Redis calls, and outbound HTTP calls, each a real span with its own start time and duration, nested exactly the way the request actually called them.
A trace is only ever captured, let alone sent over the wire, once its own root span's duration crosses a configurable threshold (1 second by default), decided entirely client-side before a single byte leaves the process. A normal, fast request never generates a trace at all; this is built for answering "why was this one request slow," not for recording every request that ever happens.
A real nested call tree for the one request that was actually slow.
The same signals probable cause already reads
The database trend signal an incident correlates onto itself (see the probable cause feature) is the exact same number this page renders directly, not a second, separately-computed view of similar-looking data. A degraded database shows up identically whether you're looking at it from the Performance page or from the incident it likely caused.
See it on your own data
Free plan included, no credit card required. New organizations start with 14 days of Business.
Get started freeGet