Skip to main content
A run is one execution of one test in one real browser, against one address. Runs use Chromium. On the Team plan, a saved procedure can also be replayed in Firefox and WebKit (the engine behind Safari).

​
Ways to start one

Chat

Describe a test in the project’s Test tab. The planner writes the steps, then they execute.

Replay a procedure

Run on a saved procedure. No planning: the recorded steps execute directly, in the Test tab where the browser streams.

Schedule

A cron expression on a procedure, dispatched server-side. Run now is available from the same screen.

API or CLI

POST /api/runs/trigger, or testorim run. Both accept a saved procedure or an ad-hoc description.
A pull request in a linked GitHub repository also triggers runs automatically.

​
What a run does

  1. Checks the workspace’s allowance and the plan’s concurrent-run limit.
  2. Takes a test browser, or waits in line for one when every browser is busy.
  3. Plans the steps (chat and ad-hoc runs only).
  4. Launches the browser at the base address, with the chosen environment (or the project’s default one) and any saved login state.
  5. Sends every connection the page makes through a guard that refuses private and internal hosts.
  6. Streams screenshots while the steps execute.
  7. Settles the page, then writes the report and sets the verdict. The run is complete at this point.
  8. Finishes the evidence in the background: final screenshot, accessibility scan, recording and trace. Then it fires alerts and updates the pull request comment if one is linked.

​
Overriding the address

Every trigger path accepts a base-URL override, so the same test can point at a PR preview without editing it:
A run with an override does not get the project’s default environment, so that environment’s headers never reach a host they were not saved for. Named environments carry their own address and headers, and are the better choice for anything you run repeatedly.

​
Limits

The numbers for each plan are on Plans and limits.

​
Waiting for a browser

When every test browser is busy, a run from the chat waits in line instead of failing. The chat shows:
  • your place in line (“You are next”, or your number);
  • an estimate of when it starts, once the service has timed recent runs;
  • at the front of the line, a countdown to when the run will give up.
The run starts by itself when a browser frees up. If none does within 3 minutes of reaching the front, or 10 minutes in line altogether, the run does not start, and the chat says “Every test browser is busy” with a Try again button. Runs from the API, the CLI, schedules and the PR bot wait the same way. One that runs out of time ends Cancelled, with the reason in its report. When browsers are free, the line is fair between workspaces: the next browser goes to the oldest waiting run of the workspace holding the fewest.

​
Cancelling

Stop a run from the chat (Stop the test), from the active-runs pill in the corner of other pages, or with POST /api/runs/{id}/cancel. The pill asks before it cancels anything. Stopping closes the browser at once. The run keeps the steps that ran and marks the rest as not run; any pending mid-run prompt is released. It keeps no recording, trace or final screenshot, and it is stored Cancelled, with no verdict. Once the report is in, the run is complete and there is nothing left to stop. POST /api/runs/batch/{batchId}/cancel cancels every run in a batch at once, which is how you stop a fuzz batch or a matrix replay.

​
When you close the tab

Closing the tab does not cancel a run. It finishes and stores its report. A tab that reconnects within a minute takes the run over and redraws it; after that, open it from the run page.

​
When a run dies

A live run pings a heartbeat every 60 seconds. A sweeper runs every 5 minutes and cancels a run whose heartbeat is more than 3 minutes old, or whose age has passed its time limit, keeping the steps that ran. The heartbeat is what lets a legitimate 30-minute scrape survive while a crashed run is reclaimed quickly.