Find the step where your app stopped working.

Open one run and follow its browser action, page, request, console message, and available service detail in sequence. See the failed request beside the browser step that triggered it, then share the run with the engineer fixing it.

Get started free Explore the debugger

Explore a sample failure below, then watch an actual recorded run.

The payment worked.
Why is the account still locked?

Move through the captured steps. The page, requests, console and test-service records stay on the same step, so you can see where the flow broke.

The payment passed, but the access check failed.

Inspect a captured stepStep 4 of 4 · 4.1s

Step order

10.0s21.8s32.4s44.1s

Network

Console

Page

Services

northstar.test / billing 4.1s

Northstar Example app

Sam’s workspace

Your workspace

Your account is still on the Free plan.

Current planFree

Shared team projectsPro required

Check that the account can use Pro features

200GET /api/account

Response body

{
  "plan": "free",
  "access": false
}

Sample data · no connection to your appSelect steps and tabs to explore

Illustrative checkout failure. Select “Receive callback,” then compare the failed request with the passing example.

Follow the payment.
Find the first visible failure.

The last assertion tells you the account is still locked. The earlier callback tells you where to start investigating.

Why is Pro access missing?

The payment was accepted, but the callback returned an account-update error. The final account check still returned the Free plan.

Example investigation · each reference opens the captured detail in the illustration above.

Check the callback handler next.

Inspect the code and dependencies behind account_update_failed. The request identifies where the visible failure begins; it does not establish which line of code caused it.

Then verify the customer result.

After a fix, rerun from the same test account and service state. Check both callback delivery and Pro access. A successful payment alone would miss the bug again.

Prepare repeatable service state

Compare the same flow
from the same starting point.

Use a passing run with the same task, account role and test-service setup. An unrelated green run can produce an unhelpful diff.

Example comparisonPassingFailing

PaymentSucceededSucceeded

Callback200 · delivered500 · failed

AccountPro · accessFree · locked

Keep the failure.
Keep your existing tests.

Start with the capture path your runner supports. Bring the run ID and its available artifacts into the investigation.

Already running Playwright?

Add this option to your existing config to retain traces for failed tests. Playwright records actions, DOM snapshots, network and console activity; its viewer can inspect them locally.

playwright.config.ts · merge into your existing config

import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: { trace: 'retain-on-failure' },
});

Record a local test and open its saved trace

npx playwright test e2e/checkout.spec.ts --trace on
npx playwright show-trace path/to/trace.zip

Replace the test and trace paths. The first command runs your test; the second opens the saved recording. These are Playwright commands, not a Molar upload.

Read Playwright’s capture guide

Inspect a captured Molar run.

Open the run result and check its artifact list.
Use its Trace ID to export a report or compare it with an authorized passing trace.
Keep that ID and the failing assertion with the issue or pull request.

Molar CLI · export and compare

molar trace export TRACE_ID --format markdown --output trace-report.md --json
molar trace diff PASSING_TRACE_ID FAILING_TRACE_ID --json

Use the Molar CLI after molar login. Replace all Trace IDs. Export writes a local report; it does not publish a share link. Available formats depend on the captured artifacts.

Open the Trace setup docs

Using Cypress, Selenium or another runner?

For Playwright and Cypress, add @molar/reporter to send results, traces and attachments to Molar. For other runners, talk to us. A recording from another framework does not automatically include its network, DOM or test-service state.

Ask about your test runner

Know what you can inspect.

Inspect the failed action and the requests around it. Available detail depends on your runner and capture settings.

Captured detail	The question it helps answer	What to check in your setup
Steps and assertions	Which action ran, and which condition failed?	Keep the original assertion and final run status.
Screenshots and video	What appeared in the browser at that point?	Recording availability, playback, and retention.
Network and console	Which request or browser error preceded the failure?	The captured time range, payload visibility, and redaction.
Clone state	Did the payment, message, or account record change?	The specific clone and state captured by this run.
Trace comparison	What changed between these two runs?	Comparable tasks, starting state, and both authorized trace IDs.
Exports	Can a teammate or tool inspect the saved result?	Available formats and access to the captured artifact.

Example artifact list

Browser recording: Captured
Network events: Captured
DOM snapshot: Not captured
Saved sign-in state: Restricted access

Illustrative availability states; inspect the list on your actual run.

Missing data is a limit on the investigation.

A missing DOM snapshot does not mean the page never changed. An absent request body may reflect capture settings or redaction. Check what was retained before drawing a conclusion.

Share the result with the right access.

Keep credentials and private payloads out of issue descriptions. Check the workspace’s access, masking and retention settings before capturing or sharing sensitive flows.

Read about access and data handling

Give your coding agent
the relevant part of the run.

Read the events around one step or compare two authorized traces. A focused result is easier to investigate than an entire log dump.

Read the failed request.

molar_read_trace_slice filters captured events by kind and exact step ID. This example requests up to 100 network responses.

MCP · molar_read_trace_slice

{
  "trace_id": "TRACE_ID",
  "kind": "network.response",
  "step_id": "STEP_ID",
  "limit": 100,
  "offset": 0
}

Compare it with a passing trace.

molar_diff_traces compares network, assertion, clone or DOM evidence. Both Trace IDs must be accessible to the connected workspace.

MCP · molar_diff_traces

{
  "trace_a": "PASSING_TRACE_ID",
  "trace_b": "FAILING_TRACE_ID",
  "dimension": "network"
}

Replace the Trace IDs and Step ID with values from your run. These tools read captured data; they do not start a browser or rerun a payment.

Connect Molar to your coding agent

Inspect the recording.
Run again to prove the fix.

Playback revisits saved data. A new test executes against an environment and produces a separate result. Rerunning a single step isn’t available yet.

See how proposed repairs are reviewed

Original failureKeep the assertion and captured events.
Proposed fixReview the change and prepare test state.
New runCheck the customer result and compare.

Actual controlled run · add, check, remove, check absence

A recording you can
watch and inspect.

This unedited run shows Molar adding an element, checking it appeared, removing it, and checking it was gone. Open the result to inspect the actions and checks beside the video.

The result and recording describe this four-step browser task. The checkout debugger above uses a separate, illustrated example.

Read the run and its checks Open the recorded result

Give the next person
the exact starting point.

Send the run and selected step to an authorized teammate. Include the expected behavior, the failing assertion, and the relevant captured request or service record. That is enough to begin investigating without recreating your entire environment.

Coding agents can inspect structured results through Molar’s CLI and MCP tools. Give them the relevant step or export, then check the fix with a new run.

Example issue summary

Expected: The paid account can open shared projects.
Observed: Payment succeeded; the account remains on Free.
Investigate: Account-update error in the payment callback.
Next check: Repeat with the same test data after the fix.

Connect your coding agent Explore the repair preview

Frequently asked questions

Have a specific workflow in mind?
Talk to us

Does every run include video, network logs, and clone state?

Every hosted run records a video, a screenshot for each step, a HAR network log and a Playwright trace. Clone state appears when the run used clones. Results sent from your own test runner include only what that runner captured.

Does playing a recording run my app again?

No. Playback shows captured media from an existing run. Starting a new browser task or replaying a generated test executes code again and needs its own environment, accounts, and result. Generated clean replay is still under validation in beta.

Can I compare a passing run with a failing one?

The CLI can compare two traces your workspace is authorized to access. Use the same task and comparable starting state to make the differences meaningful. The interactive comparison above uses authored sample data.

Can I use Trace alongside Playwright Trace Viewer?

Yes. Keep Playwright Trace Viewer for your existing recordings. Molar Trace organizes the captured browser steps and available service details for Molar runs. Export formats depend on the artifacts that exist for that run.

What should I include when reporting a failed test?

Include the run ID, selected step, expected behavior, failed assertion, and relevant captured request or service record. Share through a path the recipient is authorized to access, rather than copying credentials or private payloads into an issue.

Can a coding agent inspect the failure?

Molar provides CLI and MCP tools for reading run results and trace details. The agent needs the configured authentication and relevant trace ID. Read the current developer documentation for the available tools.

Will Trace tell me the root cause automatically?

Trace provides the captured details that help you investigate. A failed assertion and preceding request can identify a useful starting point, but they do not by themselves establish the root cause. Review the app behavior and verify any proposed fix.

Can I upload traces from my existing test runner?

Yes. Add @molar/reporter to your Playwright config (or its Cypress adapter) with an API token. Your tests, retries and exit status stay as they are; Molar receives the results, Playwright traces and attachments after each run.

How long are traces kept?

Screenshots, video, network logs and traces are kept for 5 days, and run records for 90 days. Download anything you need to keep. Exporting a report does not create a public link.

Can Trace inspect what a browser agent did?

Captured actions, outcomes and available decision summaries help explain the run. These are bounded run records, not a promise to expose a model’s private internal reasoning.

Where do I start with a private application?

Create a free workspace, add the app’s URL and a test account, and run the task you want to investigate. Talk to us if your app needs a special capture setup. You can inspect the public recording above before connecting your app.

Bring a failure you want to understand.

Create a free workspace, add your app’s URL and a test account, and describe the first task to check.

Get started free Talk to us

Free during the beta. No card.