What your cron schedule does on the two DST nights, tested

40 — Sat, 24 Oct 2026 11:16:05 +0000

Disclosure: I maintain Cronbell, a heartbeat monitor that evaluates cron schedules in a timezone. The behaviour below is general; the outputs are from my own implementation, so check how your scheduler treats these cases.

Two nights a year, local wall-clock time lies to schedulers.

Spring forward: a time that does not exist. In Europe/Amsterdam the clocks jump from 02:00 to 03:00 on 2027-03-28, so 30 2 * * * has no 02:30 that day. In my tests the next run after 2027-03-27 is 2027-03-29 02:30 local (00:30 UTC). The same happens in America/New_York on 2027-03-14. Some cron daemons run skipped jobs right after the jump instead, others skip them; this is worth looking up for yours.

Fall back: a time that happens twice. On 2026-10-25 Amsterdam repeats 02:00-03:00. 30 2 * * * could fire at 00:30 UTC (CEST) or at 01:30 UTC (CET). I treat the first as the real one and skip the repeat, so the job runs once. That gives a related quirk: 0 * * * * is evaluated once for the repeated 02:00 hour, so after 02:30 CEST the next expected run is 03:00 CET (02:00 UTC), not an extra one.

Consequences for monitoring

Fixed-interval monitors ("expect a ping every 24h") drift against a local-time cron for two days a year: either false alarms or a late one.
Evaluate the cron expression in the job's own timezone, and set a grace period of at least an hour for jobs near 02:00-03:00 local.
Safest of all: schedule jobs at times that are never skipped or repeated (for example 04:00 local), or run the host in UTC.

I found a real bug while writing this: my own implementation returned the later of the two occurrences on the fall-back night, which pushed one day's deadline back an hour. It is fixed and now has a regression test for these cases. If you maintain a scheduler, test your overlap case.

Related copy-paste heartbeat examples for crontab, systemd timers and Kubernetes (including timeZone): https://github.com/jinqo/cron-heartbeat-snippets

How does your cron or systemd timer behave on the repeated hour? I'd like to compare notes.

Five reasons your cron job failed silently (and how to catch each one)

40 — Fri, 23 Oct 2026 21:52:36 +0000

Disclosure: I maintain Cronbell, a small heartbeat monitor. Everything below works with any heartbeat service, including self-hosted Healthchecks.io.

MAILTO is silent when nothing runs. It mails only when a job prints output and needs a working mail setup. If crond is stopped, the host is down or the crontab was replaced, you hear nothing.
; instead of &&. backup.sh ; curl $PING pings even when the backup failed. Use backup.sh && curl $PING.
Output sent to /dev/null. The failure happened and you discarded the evidence.
DST and timezones. 30 2 * * * does not exist on the spring DST change in many zones and occurs twice in autumn. A fixed 24-hour interval drifts against it; a monitor that evaluates the cron expression in your IANA timezone does not.
Grace shorter than the runtime. A 40-minute backup with a 15-minute grace alerts every night until you learn to ignore it.

The fix is a heartbeat: the job requests a URL on success, and the service alerts when the request is late. Send /start first and /fail on error if you want runtime and explicit failures.

I collected tested, service-agnostic examples (crontab, systemd timers, Kubernetes CronJob with timeZone, restic, borg, a wrapper script that preserves exit codes) here: https://github.com/jinqo/cron-heartbeat-snippets

Which of these has actually bitten you, and how did you find out?

DEV Community: 40

What your cron schedule does on the two DST nights, tested

Five reasons your cron job failed silently (and how to catch each one)