Checking a timetable before you save it in Schedule

A timetable that looks right is not always right, and the place to find out is before the job is saved. Schedule by Zaweba describes every timetable back to you in words, such as At 23:30, on the last Friday of the month, and lists the next 10 times the job will run. You read it, compare it with what you meant, and only then save.

It works for both ways of writing a timetable. Type it in plain English, such as every weekday at 7:00, or as a 5-field cron expression, and the preview reads it back the same way.

Why a preview matters so much

Most scheduling mistakes are not typing errors. They are a timetable that means something slightly different from what you intended. A job meant for every weekday that also runs at weekends. A monthly report that runs on the first of the month when you wanted the first working day. A cron line where the day of the month and the day of the week combine in a way you did not expect.

These mistakes are silent. The job runs, just at the wrong times, and you might not notice for weeks. Seeing the next 10 run times as real dates makes them obvious straight away. If the list includes a Saturday, you know.

Reading the description

The words come first. They are Schedule's own reading of your timetable, put plainly. If they say what you meant, good. If they say something else, the description tells you which part to change.

Plain-English timetables have a builder alongside the text that stays in sync with it, and a word Schedule does not understand is reported, never guessed at. A monthly or yearly timetable with no time runs at 9:00 and says so, so the preview never leaves you wondering when on the day something will happen.

Reading the run times

Then look down the list of 10. Check the first one: is it when you expect the job to run next? Check the gaps: are they the interval you meant? Check the days: any weekends, any bank holidays you meant to skip? If the job uses UK bank holidays, those days are skipped, and working day follows the same calendar.

For a job that repeats every few minutes, 10 runs cover only a short spell, so check that it starts and stops when it should within a window such as every 15 minutes between 9:00 and 17:00. For a monthly job, 10 runs cover most of a year, which is a good way to see how it handles short months and the last Friday.

Comparing English with cron

Because the preview works for both, it doubles as a translator. People who think in cron can type a line and read back what it means in words. People who prefer English can write the timetable plainly, then look at the run times to be sure.

Cron has some corners that are easy to get wrong. Schedule supports lists, ranges, steps, month and day names, L, L-3, 15W, LW, 5L, 5#3, 0 or 7 for Sunday, and @hourly, @daily, @weekly, @monthly and @yearly. When both day fields are set, a day matches if either does, as in Vixie cron. That last rule surprises many people, and the run times show the effect plainly.

A habit worth keeping

Read the preview every time you change a timetable, not only when you create a job. Small edits, such as moving a time or adding a day, can have larger effects than expected.

And once a job is saved, the history tells you what actually happened: what started each run, when, and how it ended. The preview shows what should happen; the history confirms it did. Together they take the guesswork out of scheduling in Schedule by Zaweba.