Debug & fix
Use this page to pick the right tool when a script fails.
| You want to… | Use | Works on |
|---|---|---|
| Pause a run, try a fix and keep going | Live debugger | Queued or running dev runs, jobs and suite scripts |
| See why a finished run failed | Replay | Finished runs |
| Fix a broken locator after a failure | Healer | Failed job and suite runs |
| Do any of this from a terminal or with an AI tool | CLI and AI | All of the above |
A typical case: a checkout fails because a button changed. Open the debugger, try a better selector on the live page, retry the call and keep going. The fix is saved as a patch you can review and commit. If the run failed overnight, open its replay to see the page as it was, or review the heal Reflex suggested.
Open a run
Section titled “Open a run”Open Runs, select a run and use its Debug, Watch or Replay link. For a suite, pick a script first: each script has its own debugger and replay. A shared /debug/<runId> link opens the same page after you sign in.
Watch follows a run without controlling it and never makes it pause.
Who can do what
Section titled “Who can do what”- Watching and reading replays need access to the project and the run.
- Controlling a run needs the
DEBUG_RUNSproject permission. For a token, add theruns:debugscope. - Runs only pause on failures or breakpoints while a control client is attached. An unattended run never waits.
- Control commands are audited, and a paused run shows who paused it.
A person in the web UI and an AI tool can work on the same run. They share breakpoints, patches and an activity feed. Commands are handled in arrival order, so check the current pause before you act.