The server half of the story.
A replay shows you the request went slow. App Monitor shows you why: the span that served it, the query underneath, and how far off its own baseline it ran. Point any OpenTelemetry exporter at LogClip and it starts answering.
The request, the span, and the query underneath.
6 stops, each one a real screen from the console.
Four numbers, judged against a usual day
Four numbers, and the one that earns its place is latency drawn against the same hours on previous days — so a busy Tuesday reads as busy, not as an incident. Hover any chart and all three move to that moment together.
The worst requests, with their replays
The slowest requests in the window, and beside them the failures grouped — so twenty-one identical 500s are one line you can act on rather than twenty-one you scroll past. Every row opens the trace behind it.
Every endpoint, coloured against its own history
Each endpoint is judged against its own history rather than a threshold someone typed in: a route that always takes 700 ms is fine at 700 ms, and one that usually takes 40 is in trouble at 200. The table under it shows the shape, not an average.
One hexagon per endpoint, coloured by deviation from its own baseline — not by absolute milliseconds.
The spans behind the requests
Open one and the waterfall tells you the thing a duration cannot: self-time apart from time spent waiting on a child, so you learn whether the request was slow or was only waiting for something else that was.
Eighty most recent, newest first — filter to errors only.
Every database call, ranked by the time it costs
Postgres, MongoDB and Redis are fingerprinted the same way and ranked in one list by the time they cost you, not by how often they run — which is how a query running a quarter as often as the next one ends up at the top.
What your service waits on
Your service is only as quick as the things it waits on. Every outbound call gets the same judgement your own endpoints get, against its own baseline — so “Stripe is slow today” stops being a hunch and starts being a row.
Everything under app monitor
OpenTelemetry traces, endpoint latency, database calls and the services you depend on — joined to the session replay of the person who triggered them.
OpenTelemetry native
Standard OTLP over HTTP. Any exporter works; the LogClip agent can also auto-instrument a Node service with one command.
The golden signals
Throughput, error rate, p95 latency and LLM spend on top, with the same-time-of-day usual drawn behind latency so a busy hour reads as busy, not broken.
Health against its own baseline
Every endpoint is a hexagon coloured by how it compares to its own history — healthy, elevated or degraded — with a why-degraded drawer when it isn't green.
Endpoint table
p50 / p95 / p99 per route from exact histograms, a latency distribution per row, traffic, and a link to the slowest trace.
Trace waterfall
Every span in order with self-time and time waiting on children; click one for its attributes. The log lines that request emitted come with it, and the replay it came from is one button away. Errors-only filter over the eighty most recent.
Query analytics
Postgres, MongoDB and Redis calls fingerprinted into shapes and ranked together by time consumed, with calls, average, p95 and a link to the slowest trace that ran each one.
Dependencies
Every outbound HTTP and database peer gets its own row, with p50 / p95 / p99, error rate, traffic and the same elevated-against-its-own-baseline judgement your endpoints get.
LLM spend
GenAI spans read as usage: input and output tokens, cost and p95 per service, provider and model, with today's spend available as an alert metric.
Session ↔ trace
The tracker puts a W3C traceparent on first-party requests, so a request in the replay opens its trace and a trace opens its replay.
Alerts
p95 latency, error rate, throughput, deviation from an endpoint's own baseline and daily LLM spend — scoped to a service or a single route, delivered to the same inbox and email as everything else.
Why it matters.
From the click to the span
The tracker puts a W3C traceparent on first-party requests, so a network call in the replay opens the exact backend trace that served it. The link works in both directions.
Slow query, real session
Query analytics fingerprint your SQL and surface the slowest shapes. From any one of them you can open the actual user session that ran it — not a synthetic reproduction.
Judged against its own baseline
Latency is coloured by deviation from each endpoint's own history — measured against the same hours on previous days once there is enough of it — so a busy Monday does not read as an incident.
Minutes, not quarters.
Point your exporter at us
One OTLP endpoint and a key, or let the agent instrument the service for you.
Traces meet sessions
The traceparent from the browser stitches the two halves together automatically.
Open either end
Start from the session or start from the span — both routes reach the same moment.