Cron schedules
Watch a job that runs at set times, like 02:00 on weekdays, on its own schedule rather than an interval.
An interval suits things that ping all the time. A backup at 02:00 on weekdays doesn't: there's no interval that says "expect it on Monday to Friday nights". So a heartbeat monitor can expect its heartbeats on a cron schedule instead.
Setting one up #
On Add heartbeat monitor (or when editing one), under Expected, choose On a schedule:
| Setting | Meaning | Default |
|---|---|---|
| Cron schedule | When the job runs, as in crontab. | none |
| Timezone | The timezone of the machine that runs it, like Europe/London. | UTC |
| Missed runs before down | How many runs may pass without a heartbeat. | 1 |
| Grace | How long a run may take. | 5m |
Have the job ping when it finishes, so a heartbeat means the run completed:
0 2 * * 1-5 /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://ping.lastseen.io/YOUR-KEYThe schedule #
Five fields, as in crontab: minute, hour, day of month, month, day of week.
| Schedule | Runs |
|---|---|
0 2 * * * | 02:00 every day |
0 2 * * 1-5 | 02:00, Monday to Friday |
30 */6 * * * | Every six hours, at half past |
0 9 1 * * | 09:00 on the first of each month |
*/15 9-17 * * mon-fri | Every 15 minutes in working hours |
@daily, @hourly, @weekly, @monthly, @yearly | As they say, at midnight or on the hour |
Each field takes a value, a list (1,15), a range (1-5), a step (*/10) or * for any. Months and days can be names (jan, mon); Sunday is 0 or 7.
A schedule that can never run, like 0 0 30 2 * (30 February), is refused.
How runs are expected #
Each heartbeat counts for the nearest scheduled run, before or after it. A job that finishes at 02:07 has done its 02:00 run; one whose clock is a few seconds fast and pings at 01:59:58 has too. The next run is then expected, and:
- the monitor is late, then down, once that run's time plus the grace passes without a heartbeat;
- with more than one missed run allowed, it's down when the last of them plus the grace has passed.
For the backup above, pinging at 02:07 on Monday: the next run is Tuesday 02:00, so without a heartbeat it's down at 02:05 on Tuesday (with 5m of grace). A backup that can take an hour needs an hour of grace.
The monitor's page shows the schedule, the next run, and the last day as half hours, marking only those with a run due as missed.
Timezones and daylight saving #
Times are wall-clock times in the schedule's timezone, as the machine running the job keeps them: 0 2 * * * in Australia/Sydney is 02:00 in Sydney, summer and winter.
When the clocks change:
- Going forward: a run in the skipped hour (02:30 on the night the clocks jump from 02:00 to 03:00) isn't expected that night. Cron programs disagree on whether it runs at all, and expecting a run that never comes would be a false alarm.
- Going back: a run in the hour that happens twice is expected once.
Use the timezone the job's machine uses. If the machine runs on UTC, as many servers do, leave the timezone as UTC and write the schedule in UTC.
Through the API #
curl -X POST https://app.lastseen.io/api/v1/monitors -H "Authorization: Bearer $LASTSEEN_TOKEN" \
-d '{"name": "backup", "schedule": "0 2 * * 1-5", "timezone": "Australia/Sydney", "grace_seconds": 1800}'Sending interval_seconds later switches the monitor back to an interval.