When a Schedule does not produce the run you expected, one of two different things happened. Either the Schedule was paused, which it tells you about and which stops every future run until you fix the cause, or a single occurrence was skipped, which it does not tell you about and which resolves itself by the next occurrence. Start by opening the Schedules tab on the Test Set and reading the Status column, because that one column separates the two cases.
If the Status is Paused
A Schedule stops firing the moment something it depends on breaks. It is not deleted, and neither are the runs it already produced. If a person paused it, no reason is shown, because nothing is wrong. If the Schedule paused itself, the reason appears under the status, and Resume stays unavailable until you fix the cause.
Reason shown | What happened | How to fix it |
Test Set has no Test Cases | Every Test Case was removed from the set, so a run would have tested nothing | Add at least one Test Case back to the Test Set, then select Resume |
Test Set deleted | The Test Set the Schedule points at no longer exists | Recreate the Test Set and add a new Schedule to it. The old Schedule cannot be pointed somewhere else |
Environment deleted | The Environment saved on the Schedule was removed from the Test Project | Recreate the Environment, or select Edit on the Schedule and choose a different one, then Resume |
Project deleted | The Test Project itself was deleted, which pauses every Schedule inside it | Restore the Test Project. Until then nothing in it runs |
When you select Resume, the next run is calculated from that moment. Occurrences missed while the Schedule was paused are never made up. A Schedule paused for a week runs once when you resume it, not seven times.
If the Status is still Active
An Active Schedule that produced no run means a single occurrence was skipped. Two conditions cause this, both temporary:
A run from this same Schedule was still going. A Schedule never overlaps itself. If the previous run has not finished by the time the next occurrence is due, that occurrence is dropped rather than queued, so a slow Test Set cannot pile up runs behind itself. This is most common on Hourly Schedules whose Test Set takes longer than an hour.
Your workspace had no credits left. A run that cannot be paid for is not started. Running out of credits deliberately does not pause the Schedule, so it starts working again on its own once credits are available, with nothing to re-enable.
A skipped occurrence is not currently recorded anywhere you can see. The Schedule stays Active, Next run is unchanged, and no message appears. The only visible sign is a missing run, so you have to look for what is absent rather than for an error.
How to tell which one it was
Open the Set Runs tab and use View its runs on the Schedule to filter to that Schedule's own runs.
Look at the run before the one you expected. If it was still going when the next occurrence was due, the overlap guard skipped that occurrence. Compare its start time and duration against the Schedule's rule.
If the previous run finished in good time, check your credit consumption for the period the run was due. A workspace that ran out of credits overnight is the usual explanation.
If the run happened but you did not find it
Scheduled runs are not kept anywhere separate. They appear in the Test Runs list with every other run, marked Scheduled in the Execution Mode column, next to App for runs a person started, CI, and MCP. Filter that column to Scheduled to see only runs a Schedule produced.
If you are looking at a Test Set's Set Runs tab and a filter is applied to one Schedule, runs from the set's other Schedules are hidden. Clear the filter to see everything the set has run.
Other reasons a run may not look right
The run happened at a different time than you expected. A Schedule runs in the timezone of the person who created it, read from their browser at that moment and then stored. It is not your timezone, and it is not the Test Project's. The Frequency column names the timezone under the rule, and the Next three runs preview in the dialog does the same before you save.
The run covered the wrong Test Cases. A Schedule runs the Test Set's contents as they are at the moment it fires, so a Test Case added or removed during the day changes what the next run covers. This is intended.
The run used settings you have since changed. Execution settings are copied onto the Schedule when you save it and are not updated afterwards. Select Edit on the Schedule to bring them up to date.
The Persona or device on the Schedule was deleted. The run still happens, falling back to the Test Project default, and the Schedule is not paused. The run records which Persona it actually used.
A Test Asset the test needs is missing. The run starts and fails with that reason. The Schedule keeps running on its rule, so the next occurrence will fail the same way until the asset is restored.
Frequently asked questions
Does pausing a Schedule delete the runs it already made?
No. Deleting the Schedule does not delete them either. The confirmation says "Past test runs will not be affected."
Can I still run a paused Schedule?
Yes. Run now works on a Paused Schedule, because pausing stops the timer rather than the button. It does not change when the next scheduled run is due.
Will Thunders catch up on runs it missed?
No. Missed occurrences are never made up, whether the Schedule was paused or an occurrence was skipped. The next run happens at the next occurrence of the rule.
Two Schedules on the same Test Set fired at once. Is that a problem?
No. Both run. They are separate Schedules with their own settings, so neither blocks the other. The overlap guard only stops a Schedule from overlapping itself.
A person started a run at the same time as a scheduled one.
Both run. The overlap guard applies only to a Schedule against its own previous run.