A Schedule runs a Test Set on a recurring rule, so nobody has to open the project and press Execute. You create one from the Schedules tab of the Test Set, choose one of five frequencies, and pick the Environment and settings every run should use. A Schedule points at the Test Set itself, so each run executes whatever the set contains at the moment it fires.
Why a Schedule points at the Test Set and not at a list of Test Cases
A Schedule is attached to a Test Set, never to the individual Test Cases inside it. Add a Test Case to the set and the next scheduled run covers it. Remove one and the next run stops covering it. You never go back and update the Schedule to keep it in step.
One Test Set can carry several Schedules, because each Schedule keeps its own Environment, Persona and execution settings. That is what lets "every weekday at 06:00 on Staging" and "monthly on Production" be two Schedules on a single Test Set rather than two separate Test Sets.
Before you start
The Test Set needs at least one Test Case. You can still open the dialog on an empty Test Set, but it explains "Add at least one Test Case to this Test Set before scheduling it", and Create Schedule stays unavailable until the set has a case.
Your Test Project needs at least one Environment. Environment is the only execution setting a Schedule requires.
Any project member who can open the Test Set can create, edit, pause, resume and delete any Schedule on it, including Schedules somebody else created.
Open the Schedules tab
The Test Set page carries three tabs: Test Cases, Set Runs and Schedules. Each one shows a count of what it holds. A red dot beside Schedules means at least one Schedule on this Test Set has been paused automatically, so you can spot a problem without opening the tab.
Create a Schedule
Open the Test Set and select the Schedules tab.
Select New Schedule. The dialog opens with this Test Set already fixed, so there is nothing to pick.
Leave Name empty to accept the generated name, or type your own. The placeholder previews what will be saved, and it updates as you change the frequency and the Environment.
Choose a Frequency, then set the one control that frequency needs.
Choose the Environment, which is required, and a Persona if you want one other than the default.
Expand Execution settings to review the browser, device, resolution, location, Test Assets, variables, retries, parallelism, execution mode and failure behaviour this Schedule will use.
Check Next three runs, which lists the next three occurrences and names the timezone they are calculated in.
Select Create Schedule.
The five frequencies
Frequency | What you set | Example rule |
Hourly | Minute past the hour | Every hour at :15 |
Daily | Time | Every day at 02:00 |
Weekdays | Time | Every weekday at 06:00 |
Weekly | One or more days of the week, and a time | Every Monday at 09:00 |
Monthly | A day of the month, and a time | 15 of the month at 03:00 |
Three limits are worth knowing before you choose:
Hourly is the fastest rule available. The dialog says so directly: "Hourly is the floor. There is no sub-hourly option." Nothing runs more often than once an hour.
Monthly stops at day 28. The dialog explains "Any day from 1 to 28, so the run happens in February too." There is no option for the last day of the month.
The timezone comes from whoever creates the Schedule. There is no timezone control. The dialog reads the timezone from your browser once, when you open it, and stores it on the Schedule. A colleague in another country who creates "every day at 09:00" on the same Test Set gets a rule that fires at a different moment than yours. The Next three runs preview names the timezone it used, so check it before you save.
Settings are fixed at the moment you save
A Schedule stores its own copy of the execution settings when you save it. Later changes to the Test Set's own settings do not reach a Schedule that already exists. This is deliberate: a nightly run should not quietly change behaviour because somebody adjusted a default during the day.
The contents of the Test Set are the exception, and the one thing that is always read fresh at run time. To change how a Schedule runs, open its Edit action and save again.
What the Schedules table shows
Column | What it shows |
Name | The name you typed, or the generated one |
Frequency | The preset, with the rule in words underneath and the timezone it runs in |
Runs as | The Environment, with the Persona underneath |
Next run | When the Schedule fires next. A Paused Schedule shows a dash |
Last run | The outcome of the most recent run. Select it to open the list of runs this Schedule has produced |
Status | Active or Paused. A Schedule paused automatically also shows the reason |
Created by and Created at | Who added the Schedule, and when |
The table is sorted by Next run, soonest first, so the Schedule that fires next is always at the top.
Manage a Schedule
Every row carries a Run now action, and a menu with the rest:
Run now starts a run immediately. It works on a Paused Schedule too, because pausing stops the timer rather than the button, and it does not shift the next scheduled run.
Edit reopens the dialog. The Test Set never changes.
Pause and Resume stop and restart the timer. Resuming recalculates the next run from the moment you resume.
Duplicate copies the Schedule and creates the copy Paused, so it cannot fire before you have checked it.
View its runs switches to the Set Runs tab, filtered to this Schedule.
Delete asks to confirm, and tells you "Past test runs will not be affected."
Find the runs a Schedule produced
Scheduled runs appear alongside every other run. On the Test Runs list, the Execution Mode column reads Scheduled for them, next to App for runs a person started, CI, and MCP. You can filter that column to see scheduled runs on their own.
Scheduled runs use credits exactly as manual runs do. A rule that fires hourly costs roughly twenty four times what the same set costs once a day, so it is worth checking your credit consumption after the first week of a new Schedule.
See which Test Sets are scheduled
The Test Sets list has a Schedules column. It shows the frequency of the Schedule that fires soonest, a count of any others, and the next run underneath. A Test Set whose Schedules have all been paused automatically shows the reason here in red rather than a dash, so the breakage is visible from the list.
Frequently asked questions
How do I run a Test Set more often than hourly?
Trigger it from your pipeline, which can fire at whatever interval you choose. Inside Thunders, Hourly is the shortest Schedule interval, and the dialog says so: "Hourly is the floor. There is no sub-hourly option."
Which timezone does my Schedule use?
The one your browser reported when you opened the dialog. It is stored on the Schedule and does not follow you if you travel, and it is not shared across the team. Check the Next three runs preview before saving, because it names the timezone it used.
What happens if I add a Test Case after creating the Schedule?
The next run includes it. A Schedule points at the Test Set, not at a fixed list, so the set's contents are read fresh every time it fires. Execution settings behave the opposite way: those are copied when you save and do not follow later changes.
How do I resume a Schedule that paused itself?
Fix what the Status column names, then select Resume. The column always tells you the cause, for example an empty Test Set or a deleted Environment, so the repair is a short and specific job.
What happens to past runs when I delete a Schedule?
They are kept. The confirmation states it plainly: "Past test runs will not be affected." Every run stays in the Test Runs list with its report intact, so deleting a Schedule is safe once you no longer need the rule.
How do I refresh the Last run status?
Leave the Schedules tab and come back. The Last run cell reads its status when the tab opens, so returning to it shows the settled result. The run itself always completes normally.