See what broke, not just where they clicked

Replay DevTools

Click the failure, go to the moment

An example. A trial user clicked "Pay" three times and left. Did the payment call fail, or did nothing happen? The recording does not show this. The drawer shows it.

Press D, or open "</> DevTools" in the replay header. The button shows a red badge in words, such as "1 failed". Click an entry, and the replay goes to just before it. "Pay, pay, pay, leave" becomes "the payment call timed out after the first click".

• Console. Errors, warnings, info and logs, with the file and line that each came from. JavaScript errors keep their message and stack trace.
• Network. Each fetch and XHR request, with its method, its status in words ("404 Not Found", "Timed out"), its size and its duration. "Failed only" hides the rest.
• Performance. How fast each full page load showed its main content (LCP), answered a click or a tap (INP) and held still (CLS). Also FCP and TTFB. Each is rated Good, Needs work or Poor.

How it works

On the web, our recorder runs in the user’s browser, next to your analytics SDK. It captures what the page did. When a session arrives, Sequential counts its JavaScript errors and failed requests. It is a count, not a guess.

These counts drive the badges and the filters below. The judge behind Watch and Ask reads them too. The failed requests in Findings come from the same capture.

All four captures are on by default. You can switch off each one for each project.

Stop sampling. Open the sessions that broke.

On Sessions → Latest, a Problems column shows the JS errors and failed requests of each session as badges: "2 JS errors" in red, "1 failed request" in amber. "12+ JS errors" means at least 12.

Filter with "With JS errors" or "With failed requests". When both are on, both must match. The filters search the whole date range.

A missing badge never means "all clear". Sequential never shows a session that it could not check as 0. A note under the filter counts those sessions, for example: "4 sessions in this range couldn’t be checked for this filter (that capture was off, or wasn’t reported)." An empty tab tells you why it is empty.

From 38 stuck people to a measured release

Example: Northlight Outfitters, our fictional demo shop.

Sequential finds a failed request on the shipping page. It hits 38 people. In plain words: people get stuck at the shipping address.

The team filters to "With failed requests" and opens a session. POST northlight.example/api/address returns 422. The Console shows an uncaught exception just after it.

On the exception, a developer clicks "Ask your agent" and sends the prompt. Their agent reads the code and finds the postcode check that rejects a space. It files WEB-231 in the team’s tracker.

Release 2026.10.09 goes out. Sequential measures the shipping page after the release: 41% → 12% of sessions hit that failed request. Sequential gives the measurement. The team makes the decision.

Your agent reads the same counts

• From the drawer. On an exception, or on a console error with its text recorded, "Ask your agent" opens the coding agent on your computer with a prompt about it. You review it and send it.
• From your agent’s questions. Through the Sequential MCP connection, read-only session tools return the counts of each session.

you    › Which sessions since yesterday had failed requests?

agent  › calling list_sessions { "days": 1, "has_failed_requests": true }

         3 sessions had failed requests. 2 more could not be checked for this.

When a kind was not captured, its count comes back as null, never 0. So your agent can tell silence from a clean run.

Good to know

• No headers, bodies or WebSocket frames. You see which call failed, when, its status and its timing. You do not see what the server replied.
• Console text is off by default. A row reads like "console.log at cart.js:42" until a project turns on Record message text. Exception messages stay either way.
• Performance covers full page loads. Sequential does not measure route changes in a single-page app.
• Badges cover JS errors and failed requests. A problem that throws no error and fails no request gets no badge. There is no filter for console errors.
• Mobile apps get Console and Network only. Logs need Record message text, and some SDKs need a switch too. Sequential cannot see a request that got no response, so the mobile failed-request count is a floor. The Mobile apps guide lists every gap.
• Captures start when you turn them on. A capture starts on the next page load after you turn it on. Older sessions are not filled in.
• Redaction is a net, not a guarantee. It catches known secret formats. Keep message text off in production.

Questions engineers ask