From "it's broken" to the second it broke

Workflow · Bug triage

The message every team knows

Tuesday, 10:14. A customer writes: "Checkout is broken for me." There is no screenshot, no browser name and no steps.

Support asks engineering. Engineering asks for steps. The customer stops replying. By Thursday, nobody knows if it was one person on an old phone or hundreds of people who left full baskets.

The bug is not the only problem. Not knowing who it hit is the problem. Sequential turns that message into four answers.

One complaint, four answers

Sequential counts findings. It does not guess them. It checks recorded sessions against fixed definitions and counts sessions and users exactly.

• Failed request. On websites, a fetch or XHR call that returned 400 or higher, or failed with a network error or a timeout. A request that the browser cancelled because the person left the page does not count.
• Exception. An uncaught error.
• Dead click. A click on something that is not a control, after which nothing on the page changed for 1 second.

1. 01

   What happened to them?

   Paste the customer's id into the User ID filter. Their sessions come up. With the Sequential SDK, the sessions from before they signed in come up too. Click the failed-request marker on the timeline. DevTools opens on that request, with its status, such as "500 Internal Server Error" or "Timed out", and its duration. Press C for a link that opens paused at that second.

2. 02

   Is it only them?

   A JavaScript error, a server error (5xx) or a network failure becomes a finding from the first session it happens in. Other problems, such as a 4xx response or a dead click, become a finding when the same problem hits 3 or more sessions from 2 or more people in 7 days. The finding shows a count line, for example "12 of 300 sessions on /checkout · 5 users · last 7 days". Not a finding yet, for example a single 4xx? Filter Sessions to With failed requests across every recorded session in the date range.

3. 03

   Who is fixing it?

   One click copies a fix brief for your developer or coding agent. It gives the page, the failing request, the browsers and the releases near the start of the problem. It has no user ids, emails or IPs. Everyone on the project can copy it, viewers too.

4. 04

   What changed after the release?

   Record the release and name the finding. About once an hour, Sequential measures the rate before and after the release, with margins of error. It shows things it can see that can change the rate, such as another release. It says what the rate did, never why.

Example: Northlight Outfitters, our fictional demo shop

Mara cannot get past the shipping step. Support pastes her id, nl_7f3a9c21, into the User ID filter. Two sessions come up: Monday's, before she signed in, and Tuesday's checkout. At 2:14, DevTools shows POST northlight.example/api/address with status 422. She typed her postcode with a space.

Findings already has it: "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.

It is not one customer. It is 38. The product lead's agent files WEB-231. A developer's coding agent opens a pull request from the fix brief, and the developer merges it. Release 2026.10.09 ships and names the finding.

The status line goes New › Handed off › Fix linked › Fix released › Measuring › Improved. The measurement: "After 2026.10.09, 10 of 82 sessions had it (7–21%); before, 123 of 300 (36–47%)." The result is Improved, not Confirmed fixed. It is a count before and after, not a cause.

Your agent walks the trail. You sign off.

Connect Claude Code, Cursor, Codex, Claude Desktop or any MCP client at api.usesequential.com/mcp. Your agent does the same lookup.

> Mara (nl_7f3a9c21) can't check out. Is it just her?

⏺ search_events          → 2 sessions
⏺ list_errors (session)  → 2:14  POST northlight.example/api/address → 422
⏺ list_findings          → F-12  Failed request · /checkout/shipping · 38 users
⏺ list_finding_sessions  → Tuesday's session is one of F-12's
⏺ get_fix_brief          → POST northlight.example/api/address → 422

38 people hit F-12 in the last 7 days, Mara included. Want a ticket?

Your agent then files the ticket, links the pull request and records the release.

Sequential finds, counts, records releases and measures. You review and approve.

Good to know

• Email lookup works only if your app sends the email as its user id. If not, support needs the id. Or support describes what happened in Ask. Ask finds likely sessions, but it does not count them.
• Counts cover recorded sessions. No error badge does not mean that the session was clean. Capture was possibly off.
• Sequential never records request headers or bodies. DevTools redacts the card numbers, emails and credentials that it recognises. It catches only known formats, so it is not a guarantee.
• Agents get ids, not identities. Sequential removes the names, emails and phone numbers it can recognise from what an agent reads, and never returns identity fields. Agents do see the user ids your app sends, so an email used as an id is visible.
• A quiet page may not get a result. It can end as Not measured after 28 days.
• Sequential does not connect to your tracker. Your agent files the ticket. Open a GitHub issue opens a prefilled issue in a new browser tab.
• Mobile. Replay works with supported mobile SDKs. iOS is tested with a real app on the iOS simulator only. Android is not tested with a real app yet. On mobile, Sequential cannot see a request that got no response, such as a timeout.

Fair questions

Answers, not recordings

The next "checkout is broken for me" gets an answer: the person, the second, the count and the rate after the fix.