A manual run is good when something needs checking right now. The real benefit begins when the check runs by itself — every morning before the workday starts, for example. A schedule defines on which days and at which times the test runs. Below is how to set it up and what makes it fire.
What a schedule looks like
It is a weekly grid: days of the week and times. For example, “weekdays at 9:00 and 18:00”, or “Monday at 10:00”. A moment when a test was supposed to run is called a slot — a handy word when you are figuring out why a run did not arrive.
Times follow the project’s timezone, not the server’s. This matters when the server stands in another country: a 9 am schedule means 9 am where you are, not somewhere else. The timezone is set in the project’s settings.
An ordinary run lands in the run history. When a test declares snapshots, a scheduled run also appears on the “Verify” tab — the same place manual runs go.
Missed slots are not caught up
This is the most important thing about schedules, so it is best said outright: if at 9:00 the server or the executor computer was off, that run does not happen at all. The product will not catch up on the missed slot and will not fire the accumulated checks one after another once everything is back on. The next run arrives at its own slot.
The logic is simple: a check two days after the fact is almost useless, and an avalanche of catch-up runs would only occupy the executor. When a check is needed right now — run it manually.
The other case: the server is up, and there is no executor online. Then the test goes into the queue and waits. As soon as a browser appears, the run starts — waiting is appropriate here, because the slot has just passed.
When a test is deleted
The schedule disables itself: there is no point reminding about a test that no longer exists, and no point littering reports with errors. You do not need to clean schedules up after deleting tests.
The executor machine
The reliability of a schedule equals the reliability of the machine the executor runs on. The recipe is simple: a permanently powered-on computer, a Chrome with the addon installed, runner mode enabled in the addon’s settings. It is better to dedicate a browser profile or a whole computer to this: runs then never interfere with your everyday work, and your work browser does not have to stay open around the clock.
Whether the executor is alive can be checked in the addon’s settings: they show how much time passed since the last contact. Seconds and minutes mean everything is fine; hours mean the machine is asleep, Chrome is closed or the connection to the server is gone.
When runs do not arrive
- No executor online — the computer is off, Chrome is closed or the addon is disabled. Check the last-contact time in the addon’s settings.
- The slot was missed — look at the next run time: the product shows it next to the schedule in the project. A missed slot will not come back; you have to wait for the next one.
- A different timezone — the most common invisible mistake. Check the timezone in the project’s settings: because of it, 9:00 can mean a very different time of day.
- The schedule is off — that happens after the test was deleted, or when it was disabled by hand. Enable it and save.
Next: how run results become issues — in the Issues section.