How to schedule tests to run automatically

Schedules let a test set run on its own — every hour, every weekday at 9 AM, every first of the month, whatever shape your release cadence takes. This guide walks through creating, editing, and triggering one.

Steps

Open the Schedules page

Navigate to Schedules in the top nav (or the bottom bar on mobile). If your org has none, you’ll see an empty state with a “Create schedule” button.
Click Create schedule

The form dialog opens. You’ll need a name, at least one test set, and a cron expression.
Pick a frequency

The cron builder offers four shapes:
- Hourly — runs every hour, at the minute you choose
- Daily — runs once a day, at the hour:minute you choose
- Weekly — runs on selected days of the week, at the chosen time
- Monthly — runs on a specific day of the month, at the chosen time
Underneath, this writes a standard 5-field cron expression. If you want to type one directly (e.g. 0 9 * * 1-5 for weekdays at 9 AM), the value is editable.
Pick a timezone

Defaults to UTC. Any IANA zone name works — America/Los_Angeles, Europe/Berlin, Asia/Tokyo. Unknown zones are rejected.

There’s no nightly-run option because “nightly” means something different in every timezone — you pick.
Choose test sets and browsers

Pick one or more test sets to run, and which browsers to run them in (Chromium, Firefox, WebKit). Browser selection is saved per schedule, so a smoke schedule can run Chromium-only while a release schedule runs all three.
Add notification recipients (optional)

Add email addresses that should be notified when the run finishes. Toggle Notify on failures only if you only care about red runs; leave it off to be notified on every run.
Skip if waiting longer than (optional)

For frequent schedules — every minute, every five minutes — the queue can back up if the org’s parallel-execution slots are full. By the time the executor gets to a 30-minute-old run, the next fire is already overdue. Set this field (1–1440 minutes) to skip runs that miss the window instead of executing them late. Leave it empty to wait indefinitely.

Skipped runs still log against the schedule’s history with skipped_stale so you can see they didn’t fire.
Save

The schedule is enabled by default. The next-run time computes immediately and shows in the table.

Editing or disabling

The schedule row has a toggle for Enabled. Flip it off to pause the schedule without deleting it — next_run_at clears and won’t fire until you re-enable.

To change name, cron, browsers, or recipients, click the row’s edit icon. Saving recomputes the next run.

Trigger a one-off run

Each row has a Run now action. It dispatches the same test sets the schedule would have run on its next tick, marks the schedule’s last_run_at as the trigger time, and navigates you to the Runner so you can watch progress in real time.

This counts against your monthly cloud-runs quota the same as any other run.

Deleting

Deleting a schedule cancels all its future runs and removes it from the list. Past runs already started keep their reports — deleting the schedule doesn’t delete its history.

Plan tier limits — schedule cap per tier
Sharing reports — what notification recipients see when they click the link
API keys — needed if you’d rather trigger runs from CI on a cron schedule of your own