Know what to fix on Monday, without spending Friday in replays.

Stop watching replays to size a bug

Monday, 9:40. Support sends you two emails: "Is checkout broken?" By lunch you watched eleven sessions at double speed. Two look strange, and not in the same way.

Is it one person or one hundred? Is it new? Is it worse than the bug you know about? Nobody knows, so the sprint plan waits.

Findings gives you the count before you open a recording.

Counts, not guesses

Every 15 minutes by default, Sequential checks the last 7 days of your events, and the errors and requests that the Sequential recorder captures. It uses five fixed rules: an error, a failed request, a click that does nothing, repeated angry clicks, and a click away that comes back to the same page within 5 seconds. It counts every matching session exactly. No model decides what a problem is.

A JavaScript error, a server error (5xx) or a network failure joins the list from the first session it happens in. Other problems join when they happen in 3 sessions from 2 different people in 7 days. Some noise never joins the list: errors from browser extensions, failures on ad and analytics hosts, and requests that the page or the browser cancelled.

• What happened. A fixed title made from the facts, for example "POST northlight.example/api/address fails with 422 on /checkout/shipping".
• How many. The exact number of sessions and people. When Sequential counted the page, it also shows how many sessions reached the page: "52 of 127 sessions on /checkout/shipping · 38 users · last 7 days".
• Where to look. Up to 5 sample sessions. A sample with a ready recording opens at the moment it happened.

Active problems come first. Then come the problems that hit the most people. When sessions have a judgment, a row can show a hedged line, such as "about 4 of 9 judged probably gave up (±2)". This line can move a finding up or down. It never decides what a finding is.

Each finding shows its status on a timeline: New, Handed off, Fix linked, Fix released, Measuring.

One finding, start to finish

Example: Northlight Outfitters, our fictional demo shop.

At the top of the list: "POST northlight.example/api/address fails with 422 on /checkout/shipping". Failed request · 52 of 127 sessions on /checkout/shipping · 38 users · last 7 days.

The head of product clicks "Watch from 2:14". A customer types a postcode with a space. The page sends the customer back. The customer types the postcode four more times, then leaves. Sequential counted the failed request. She saw the reason.

Her agent files WEB-231 in their tracker. A developer’s coding agent uses the fix brief and opens a pull request. The developer reviews it and merges it. When release 2026.10.09 ships, their agent tells Sequential which finding the release is for. Sequential then measures again about every hour until it has a result.

Measured after the release: 41% → 12% of sessions on the shipping page. The card says: "After 2026.10.09, 10 of 82 sessions had it (7–21%); before, 123 of 300 (36–47%)."

12% is not zero, so the card says "Improved", not "Confirmed fixed". Sequential tells you what the rate did, not why. When it sees another release or a change in traffic in the same window, the card says so.

Hand it over with the evidence

Every finding comes with a fix brief. It tells what users experienced, where, the evidence, since when, and how Sequential will check after the release. Anyone on the project, viewers too, can copy the brief into a ticket. They can also open the GitHub new-issue page with the brief filled in. You do not need an agent.

Teams with an agent can do more. Sequential does not file tickets, open pull requests or post in chat. Your agent does these things, in your tools, with your permissions.

For developers: Claude Code, Cursor, Codex, Claude Desktop or any MCP client that can send a project token connects with one. Sequential redacts user text and removes text that looks like instructions.

Good to know

• Five kinds of problem, no others. It does not flag a confusing form by itself. At Northlight, a person saw the postcode problem in the replay.
• What it counts depends on your SDK. Failed requests and the browser’s own JavaScript errors need the Sequential recorder. Errors, dead clicks, rage clicks and clicks with element text or a selector can come from the SDK you use now, if Sequential reads it and it sends them. To count a person who signs in partway as one person, your SDK must tell Sequential about the sign-in. See which SDK sends what in the docs.
• Release results wait for traffic, not for the calendar. If a problem in 10% of sessions stops completely, about 60 sessions after the release are enough. If a problem in 1% of sessions only falls by half, Sequential needs about 4,700 sessions before and after the release.
• Measuring and Not measured. Until there is a result, the card says "Measuring". If too few sessions reach the page, the result is "Not measured". The hosted preview keeps 7 days of data by default, so the before and after counts use at most 7 days each.
• The top 50. The Findings page shows the top 50 findings.
• Not every sample has a replay. Some samples open as events only, with a chip such as "Processing · ready by 14:20".
• Scheduled, not live. Checks run every 15 minutes by default. After a release, Sequential measures about every hour.
• What your agent sees. The brief has no user ids, emails or IP addresses. Session tools give your agent your user ids as you send them. If your ids are emails, your agent sees them.

Questions

You make the call

Sequential keeps the count. You make the call. Engineering, or their agent, takes it from there.