A scheduled run starts on its own: every day at a time you pick, or each time a new build of your app lands. It runs the same tests on the same devices as a run you start yourself, on iPhone, iPad and Android phones and tablets, or on Apple TV, Android TV and Roku for TV apps. AI testing is in beta.
Scheduled runs are on paid plans.
Schedule a run
- Open the Run dialog from the Tests page: the play button on a test, Run for the tests you ticked, Run group, or Run all.
- Pick the devices, start state and AI use as for any run (see Running tests).
- Under When, pick Every day or On every new build. For a daily run, pick a Time and a Time zone (your browser’s time zone by default).
- Leave Also run it now ticked to start a first run straight away. It is ticked for Every day and not for On every new build.
- Optionally, under Advanced, tick Retry a failed test once (see below).
- Click Schedule.
You need the Developer or Admin role to schedule runs. An organization can have up to 50 schedules. On the Free plan, the two choices are marked (paid plans).
What a scheduled run runs
- A group: the tests in the group when the run starts, so a test you add to the group later is included.
- All tests: every test of the app when the run starts. Saved from a product’s page (apps you linked as one product, see Apps), every test of the product on that form factor.
- One test or the tests you ticked: those tests. If one of them is deleted, the schedule pauses (see below).
Every day runs at the time you picked, following the time zone’s clock through daylight saving changes. On the day the clocks go forward, a time inside the skipped hour runs an hour later on the clock; on the day they go back, it runs once. If you picked a build in the dialog, every run uses that build. With Latest, each run uses the newest build that can run at that time.
On every new build runs a few minutes after a new build of the app lands, with that build, on the devices of that build’s platform. If you picked devices of the same app on two platforms (for example iPhone and Pixel), an iOS build runs on the iPhone and an Android build on the Pixel. Linking more apps to the product never adds devices to a schedule. When several builds land within about 3 minutes of each other, only the newest one runs. Debug builds that load their code from your computer, as used for live development of your React Native app, never start a scheduled run, and nor do builds no device can run. Builds that existed before you created the schedule don’t start it either.
If a daily run can’t start within 6 hours of its time, that day’s run is skipped. A schedule never runs several missed days at once.
Who it runs as and who pays
A schedule runs as the person who created it, its owner, shown in the list of schedules. It is billed like a run from CI:
- every device is a session that counts toward your plan’s concurrent sessions and uses streaming minutes; when no session is free, the device waits in the queue;
- AI use is paid from your usage credit or your own API key, like any run; No AI uses no usage credit;
- a failed test is not run again, unless the schedule has Retry a failed test once on: then a test that fails is run once more, and a test that passes the second time counts as flaky. A retry uses AI and streaming minutes again. Schedules created before 12 October 2026 retried by default; they no longer do until you turn it on.
Each scheduled run has a time limit, 2 hours by default and 10 to 480 minutes if you change it. It is counted from when the run is created, time waiting in the queue included. A device waiting in the queue keeps waiting for a free device up to the run’s time limit; if none becomes free by then, that device’s tests don’t run. A run still going at its limit is cancelled and its owner is told.
When a schedule pauses
A paused schedule doesn’t run until a Developer or Admin resumes it. It pauses when:
- its owner can no longer run it: they left the organization, were removed, became a Viewer, or their account can no longer be used. Everyone in the organization gets a notification. Take over and resume makes you the owner, and the schedule then runs as you;
- your organization moves to the Free plan. Upgrade, then resume it;
- something it runs was deleted: a test, the group, a build you picked, an environment, or the app on another platform;
- it has nothing left to run after an app was removed from its product: removing an app from a product takes that app’s devices out of every schedule of the product. A schedule that still has devices keeps running on them, and its owner is told once which devices it lost; one left with no devices, or whose tests or group belonged to the removed app, pauses and its owner is told. Edit it, then resume it;
- the app can’t run on your plan;
- three scheduled runs in a row couldn’t start, for example because your usage credit ran out or this month’s streaming minutes are used up. The owner is told the first time a run couldn’t start, and again when the schedule pauses.
If your subscription payment is overdue, the schedule doesn’t pause: its runs are skipped, and the owner is told once, until the payment goes through. These skipped runs don’t count toward the three. Once a run has been skipped for this, the schedule’s status reads Payment due. New schedules can’t be created until the payment goes through.
Deleting an app deletes its schedules. When the app is linked to the same product on another platform of its form factor, its schedules move to that app instead, without the deleted app’s devices.
Manage schedules
On the Tests page, open the Schedules section: Scheduled runs lists the app’s schedules with when they run, the devices, the time limit, who they run as, the next run and the last run. Viewers can see them. Developers and Admins can:
- Run now: start a run straight away, as the schedule’s owner. On an On every new build schedule, it runs every platform of the schedule on that platform’s latest build;
- Pause and Resume (Take over and resume when the owner can no longer run it, whatever paused the schedule);
- Edit: opens the Run dialog on the schedule. Change its devices, builds, AI use, start state, environment, Stop on first failure, Retry a failed test once, when it runs (Every day with a time and time zone, or On every new build), its Time limit and its Name, then click Save schedule. A device the schedule uses that is no longer available is named in the dialog; saving keeps only the devices ticked. Editing never changes who the schedule runs as, and never resumes a paused schedule;
- Delete: the schedule’s past runs stay in Runs.
A daily schedule runs at most once per day in its time zone. If you change its time, or resume it, on a day it has already run, its next run is the following day at the new time, and Next run shows that.
What a schedule runs (the test, the tests, the group or all tests) can’t be edited: to run other tests, schedule a new run from the Run dialog. The Run dialog also sets a new schedule’s Time limit.
A group with a schedule shows it next to its name, for example Daily 02:00. In Runs, scheduled runs read Daily or New build in the trigger column, and the same under Trigger on the run’s page (Schedule for a run started with Run now or Also run it now); the trigger filter has Schedule.
Notifications
When a scheduled run fails, its owner gets a notification and an email with a link to the run. A run that couldn’t finish for a reason that isn’t your app, a cancelled run and a quarantined test’s failure don’t notify as failures. Its owner is also told, in-app and by email:
- when the schedule pauses;
- when a run couldn’t start, for example because your usage credit ran out;
- when some or all of a run’s devices didn’t run its tests, for example because no device became free within the run’s time limit. The notification says how many devices didn’t run and why, and links to the run. The schedule also shows the reason in Scheduled runs until its next run starts. This never counts toward pausing the schedule;
- when a run was stopped at its time limit.
See Notifications.
API
Schedules can be listed, created, changed, run and deleted through the API; see Tests API.