Run tests and rerun the failures

There are a few places to kick off a run, one run-config popover that governs them all, a queue that holds runs until a slot frees up, and two flavors of rerun. This guide walks the whole path.

For where a run executes (Marriska’s cloud vs. your own machine) and why you’d choose each, see Cloud vs. local.

Start a run

From	How	What runs
A single test	Run Test in the test editor	Just that test (its data rows expand into iterations), in the cloud
A single test, locally	The caret beside Run Test -> On my machine	The same test, dispatched to your local agent so it can reach localhost and your intranet
A test set	The ▶ on the set header	Every test in the set, as a batch
A tag	Run by tag on the Runner page	Every test carrying the tag, across all projects
A schedule	Run now on the schedule	The schedule’s test sets, immediately

Set runs, tag runs, and run-now all open the same popover before they start:

Browsers — check any of Chromium, Firefox, WebKit. Each browser is a separate execution, so two browsers doubles the run count (and the quota cost). Every plan, Free included, can run all three.
Execute on — Cloud (default) or Local. Local is greyed out until you have a local agent connected.
Run now — commits it. There’s no separate confirm step; this is it.

The run queue

Runs don’t all start at once. How many your org executes simultaneously is your plan’s parallel-executions limit (1 on Free and Starter, more on Pro and up — see plan tiers). Extra runs sit in the Execution Queue on the Runner page until a slot opens.

A Run from the test editor takes one of the same slots. When they are all in use, the editor says Waiting for a free slot (2 of 2 in use) and starts the moment one frees, in turn with the runs queued before it. Stopping it while it waits ends it without counting it as a run.

While a run is still pending, you can:

Reorder it — drag pending runs to change which goes next.
Remove it — drop it from the queue before it starts (its status becomes removed).
Change its target — flip a pending run between Cloud and Local.

Rerun a run

From a run in your history you get two rerun buttons:

Rerun all — runs the whole set again, fresh.
Rerun Failed — runs only the tests that failed, and only on the browsers that failed. For a parameterized test, it reruns just the data rows that failed, not all of them. This is the fast way to confirm a fix without paying for the green tests again.

If you have a local agent connected, rerunning first asks “Where should this run?” — Cloud or Local. With no agent, it goes straight to cloud.

Stop a run

Action	Where	Result
Stop one run	The run’s stop control	Status → `stopped`
Stop All	Runner dashboard	Stops the active run and clears the queue
Stop one test in a running set	The test’s row	That test stops; the set continues
Remove a queued run	The pending run’s menu	Status → `removed` (it never starts)

Stopping is a deliberate, confirmed action for the bulk options — “Stop All” asks first, because it also wipes everything waiting in the queue.

Watching a run

Cloud runs stream step events back live — you’ll see each step flip from running to passed/failed in real time, with screenshots arriving as they go. To watch the actual browser window drive itself, run local with the agent’s headed mode. When the run lands, read it in the report.

Run at a phone size

Every run used to open a desktop window, whatever your product was built for. A test now declares the viewport it was written for — in the test’s properties, under Status — and a run can override it for every test it contains, from the run-config popover, a schedule, or the API.

Preset	Size	What else changes
`desktop` (default)	1920×1080	Nothing — this is what every run did before
`laptop`	1280×800	—
`tablet`	768×1024	iPad Safari user agent, touch, 2× scale
`mobile`	375×667	iPhone Safari user agent, touch, 2× scale
`mobile-large`	390×844	iPhone Safari user agent, touch, 3× scale

The mobile presets change more than the width: the user agent, touch and the device scale travel together, because responsive behaviour often keys on pointer type, not only on size. On Firefox the touch flags are not available and only the size, user agent and scale apply.

Each result in the live runner and in the report shows the preset it rendered at, so a green run at a phone size is never mistaken for a desktop one. To get evidence at two sizes, run the same set twice — once at mobile, once at desktop — or schedule both; each is its own row in the history. The preset names are stable: they are stored on your tests, and none will be renamed.

Cloud vs. local execution — where runs execute and why
Set up the local agent — required for Local runs
Reading a run report — what the run produced
Plan tier limits — parallel executions and monthly run quota