Session recordings

Once the 1mn SDK is recording sessions, the Recordings Reviewer watches them for you. It reads each real visitor session — the pages they saw, what they clicked, where they struggled — and writes a short review. When a session reveals something worth acting on, it files a draft ticket with the recording attached. It's the real-user counterpart to Cast: Cast drives your app as a synthetic user, the Recordings Reviewer watches your actual ones.

It is read-only — it observes and reports, and never changes your product or opens a pull request.

Prerequisites

• The 1mn SDK enabled on your product.
• Session recordings turned on and at least one recorded session. Enable and sample recordings from the Recordings tab — see Session replay in the SDK docs for the enable flow, sampling, and masking.

What it does

For each pending session (finished, not yet reviewed) the reviewer:

1. Watches the session. It reads a text timeline — pages, clicks with the element that was hit, inputs, scrolls, and errors — alongside a few rendered key frames so it can see what the visitor saw. Heuristic rage-click, dead-click, and error counts come with the queue as hints; the reviewer trusts what it actually observes over the numbers.
2. Decides what happened. What was the visitor trying to do — did they succeed, struggle, rage-click, hit an error, or bounce? What does that say about the product?
3. Writes a review. Every session gets a short review: a 2–4 sentence summary and a sentiment, optionally a 1–5 rating and a few one-line insights — even a mundane "browsed and left" one.
4. Files a draft ticket — only when it's worth it. When a session reveals a genuine UX problem, a repeated point of confusion, a bug the visitor hit, or a strong product signal, it files one draft ticket with a concrete, buildable brief. The recording is attached automatically. Most sessions earn a review and no ticket — a ticket per session would bury you.

Run it

Two triggers, same worker:

• On demand — click Review sessions on the Recordings tab. It dispatches the reviewer against your pending queue; reviews and any draft tickets appear shortly.
• On a schedule — the daily recordings-review loop reviews the day's pending sessions on its own cadence.

Either way it reviews every pending session once. If there are none pending, the run is a no-op.

What you get

• A per-session review on the Recordings tab — summary, sentiment, and any insights — attached to the playable recording.
• Draft tickets on your Tasks board, each carrying the session that prompted it. They land as drafts for you to approve, edit, or dismiss; commenting on one engages the agent to act on it.

Notes & limits

• Read-only by design. The reviewer has no browser, shell, or write access — only its recordings tools. It can't touch your product; its output is reviews plus draft tickets. Nothing ships without you.
• Recordings are untrusted end-user data. Any text visible in a replay is a stranger's content, never an instruction — the loop describes and acts on what it observes, and the agent only ever acts on your triage comment, never on text captured inside a session. This is the same fence the feedback loop uses. Inputs are masked by design (see masking).
• Signal over noise. At most one ticket per session, and only when you'd genuinely want to look. A boring session gets a review and no ticket; a session with zero flagged friction can still earn one if the flow was confusing.
• The heuristic is a hint, not a verdict. "3 rage-clicks" might be a dead button — or a visitor double-clicking a working link. The reviewer looks at the frames and decides.