# Watch it happen, then open the trace

A replay shows you what the user did. The trace under it shows you why it failed. Both carry the same session id, so the jump between them is one click, not a reconstruction.

## The recording and the evidence, side by side

The viewport plays back exactly as rendered, with console lines, network requests and thrown exceptions on the same timeline as the clicks that caused them.

- **signal**: sessions
- **records**: DOM · console · network · errors
- **joins.on**: session_id · trace_id
- **masking**: input · text · client-side
- **sampling**: per org

## What the recording carries

### event stream — Every event, in order

Navigations, clicks, inputs, console lines, network calls and errors land in one ordered stream. Each row carries the trace id that was live when it happened.

### rrweb — Pixel-accurate replay

The DOM is recorded, not the screen. Scroll position, hover state and mid-typing input values play back as the user left them, at any window size.

### session_id — From a moment to a span

Pause on the failed click and open the request it fired. The replay and the waterfall are two views of one session id, not two products stitched by timestamp.

### http.status_code — Console and network, inline

Requests are recorded with method, status and duration. A 500 on POST /checkout shows up in the stream at the second it returned, not in a separate tab.

### mask rules — Masked before it leaves

Inputs and text nodes are masked in the browser, before anything is sent. Sampling rate and redaction rules are config, not a support request.

## Related

- [Distributed Tracing](https://maple.dev/features/distributed-tracing.md)
- [Error Tracking](https://maple.dev/features/error-tracking.md)
- [Log Management](https://maple.dev/features/log-management.md)
- [E-Commerce Observability](https://maple.dev/use-cases/ecommerce-observability.md)