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 Dogfooding: Cast personas drive your app as synthetic users, 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.
• No new sessions = nothing to review. The reviewer only works the pending queue. If recording is off, your sample rate is 0, or you've hit the session cap, no new sessions are coming in and a run is a no-op — the Recordings tab shows a banner when you're at (or near) the cap, so you can tell "capped" apart from "quiet".