Slow SQL attribution
That interaction opens directly.
The scene behind a slow query
Start from a slow statement in the database and end at the click that caused it. No frontend instrumentation, no re-enactment.
Slow query to replayDiting
01Slow query
SELECT … WHERE order_id = ?02Owning request
03User session
Replay and signals share correlation keys
It uses the same correlation keys as traces, logs and database statements; opening replay takes you to that request.
- Slow SQL links straight to the session
- Frontend errors line up with backend exceptions
- User paths replay in order
- Share links keep the full context
SQL, request, session
Find the statement
Sort by duration in QAN or a trace and open the statement and its plan.
Land on the request
The statement hangs off a span with services, duration and errors attached.
Find the session
The request is tied to a browser session with clicks, typing and navigation.
Open the replay
Reconstruct the page, see where it stalled and what it threw.
Common scenarios
Frontend errors
What the user clicked before the error, and what the page showed.
User paths
From entry to failure, every step is reviewable.
Share and collaborate
Send a timestamped link; the recipient opens the same scene.
Replay capabilities
| Capture | The agent injects RUM at the nginx or container layer. No frontend code changes. |
|---|---|
| Coverage | Injection coverage per application, so you know which pages are captured |
| Links | trace_id and session_id jump both ways |
| Privacy | Input masking and field-level blocking |
Fits
- Web frontends where user-side problems must be traced
- Legacy systems where frontend code cannot change
Doesn't fit
- Backend-only services with no browser interaction
- Compliance regimes that forbid session capture
Bring your system in
Tell us what you run: OS, kernel, public network or not, virtual machines or clusters. We will map the path in.