Every test records what its browser logged: the console messages your app wrote and the network requests it made. They are at the bottom of the test’s page, under the step timeline, and help explain failures the page itself doesn’t show, such as a JavaScript error or an API call that returned 500.

Console
Section titled “Console”The Console tab lists the messages the page wrote to the browser console, oldest first, each with its level. Filter by level: ALL, ERROR, WARNING, INFO, DEBUG or LOG. The tab’s badge counts the errors.
Errors in the console are not failures by themselves: many sites log errors that change nothing for the user. They matter when they line up with a failed step.
Network
Section titled “Network”The Network tab lists the requests the page made, with their status, method, URL and type. Filter to ALL, ERRORS (failed requests), 4XX or 5XX. Click a request for its details.
Use it to answer “did the request even succeed?”: a step that waits for a message that never appears often has a 4XX or 5XX request just before.
When Self-driving investigates a failed run, it reads both tabs too: console errors and failed requests are part of the evidence behind its verdict.
What is recorded
Section titled “What is recorded”- Everything from the start page to the verdict, including automatic login.
- Up to 500 console messages and 1,000 network requests per test, each cut to at most 2,048 characters.
- Secrets are removed from URLs before they are stored: user names and passwords in URLs, and the value of every query parameter, which is shown as
REDACTEDwith its name kept, so?code=REDACTED&state=REDACTEDstill tells you what the request was. - Every project member can read the logs, Viewers included, as with the rest of a run.