Paste the error, its call log and the error-context.md snapshot. See the failing step, the likely cause from the log, and whether a dialog sits on top of the target.
A Playwright click, fill or assertion times out when the element is missing, covered by another element, hidden, disabled or still moving, and the call log lines under the error say which of these it was. This page reads those lines for you. Paste the failing test's error output in the first box: the header with the test title, the Error line, the Call log block and the stack. The tool pulls out the test title and file location, the API call (such as locator.click), the locator, the timeout in milliseconds, and for assertions the Expected and Received values. Playwright prints repeated call log lines once with a count, for example 9 × locator resolved to 0 elements; the tool reads those counts and adds them up.
The wording comes from the Playwright source (see the notes on this page). A line that ends in "intercepts pointer events" names the element that receives the click instead of your target, which is the classic overlay or cookie banner problem. "element is not visible", "element is outside of the viewport", "element is not enabled", "element is not stable", "element is not editable", "element is inert" and "element is inside a hidden frame" each mean one specific check kept failing. "waiting for" followed by a locator and no "locator resolved to" line means nothing ever matched. "strict mode violation: ... resolved to N elements" means the locator is ambiguous, and the numbered matches are listed. For expect() failures it reads the matcher, the Locator, Expected, Received and the Timeout lines, and "element(s) not found". The first pattern that applies gives the likely cause and one next step. If none applies, it says so instead of guessing.
When a test fails, Playwright can save error-context.md with an ARIA snapshot of the page in YAML. Paste it in the second box. The tool lists dialogs and alert dialogs, alert and status regions, toast or notification texts, cookie and consent buttons, and texts that look like errors. It also reads the target from the locator (getByRole with a name, getByText, getByLabel, getByPlaceholder, getByTitle) and checks whether an element with that role and name exists, whether it is marked disabled, and whether it sits inside an open dialog. Worked example: a click on getByRole('button', { name: 'Pay now' }) ends with Test timeout of 30000ms exceeded and the log says a div with class cookie-overlay intercepts pointer events. The snapshot has a dialog named Cookie settings with Accept all and Reject all buttons, and the Pay now button is outside it, so the summary says the dialog is likely on top of the target and suggests closing it first. Locators written as CSS selectors or test ids, and name patterns that are not plain words, are not matched against the snapshot.
It reads text. It does not run your tests, open traces or look at the screenshot, and the cause is a reading of the log patterns, not proof. A timeout caused by a slow server, a wrong URL or a race in your app can look like any of the patterns above, so treat the next step as the first thing to check. Each pasted box takes up to 300,000 characters, the snapshot is read up to 5,000 elements and the call log up to 400 lines. An AI agent can open this page with the error already in the first box using #input= followed by the URL-encoded text. The text is processed in your browser and not uploaded; only your option choices are saved.
Playwright found your element, but when it checked which element is at the click point, another one was there, such as a modal, a cookie banner or a loading overlay. It logs that element's tag and class, waits and retries until the action or test timeout. Close the cover first or wait for it to be hidden.
A locator used for an action or an assertion matched more than one element, for example getByRole('button') on a page with 3 buttons. Playwright lists each match with a suggested locator after "aka". Add a name, scope it inside a parent, or use .filter(); use .first() only if any match is fine.
Newer Playwright versions can write error-context.md for a failed test, in that test's folder under test-results. It has an ARIA snapshot of the page at the failure and usually the test name and location. If you have no such file, leave the box empty and the error output is still read.
An action or assertion timeout (for example an expect() that waited 5000 ms, or a click limited by actionTimeout) stops one step. The test timeout (30,000 ms by default) limits the whole test, and when it is reached while a step is running, the message reads Test timeout of 30000ms exceeded and names the running call. The call log still shows what that step was waiting for.
Being in the snapshot only means the element exists. Common reasons for a timeout anyway: it is marked disabled, an open dialog covers it, it is outside a scrolling container, or it keeps moving during an animation. This tool shows disabled and dialog findings next to the call log signal.
No. The text is processed in your browser, in this tab, and no server receives it. Your option choices are saved in this browser, the pasted text is not. Error output can hold URLs and page text, so check it before you share the summary.