Disclosure: I build Cron Toolkit and Cron Heartbeat, the tools linked below. They have free tiers. Every schedule shown here was computed with the Cron Toolkit engine, and you can paste them into the free timezone page to check them yourself.

Europe falls back on Sunday 25 October 2026: at 03:00 CEST the clocks go back to 02:00 CET. The US and Canada do the same on Sunday 1 November 2026, when 02:00 local time becomes 01:00. Each of those nights has one wall-clock hour that happens twice. If your cron jobs run in a local timezone rather than UTC, that hour can make a job run twice or not at all, depending on which scheduler you use.

1. A fixed-time job inside the repeated hour

30 2 * * * in Europe/Berlin:

The US version is 30 1 * * * in America/New_York. It runs at 01:30 EDT on 1 November, then at 01:30 EST every day after that. It runs once, at the first 01:30.

That is how Vixie cron and cronie behave. Not every scheduler does this:

(Behaviour as documented or reported by each project. Test your own version before relying on it.)

If a job isn't idempotent, such as billing, emails or ledger exports, a scheduler that runs it twice is a real bug.

2. Wildcard-hour jobs run in both passes, and that's correct

30 * * * * in Europe/Berlin on the night of 24–25 October:

00:30 +02:00  (22:30Z)
01:30 +02:00  (23:30Z)
02:30 +02:00  (00:30Z)
02:30 +01:00  (01:30Z)   <- same wall time again
03:30 +01:00  (02:30Z)

An hourly job should still run every real hour, so you get 25 runs that day. That's fine for hourly jobs. It confuses dashboards that key on local time, though, because two runs share the label "02:30".

3. Spring forward: the job that never runs

Europe springs forward on 28 March 2027, when 02:00 becomes 03:00. 30 2 * * * Berlin:

2027-03-27 02:30 +01:00
2027-03-28 (no 02:30 exists; skipped)
2027-03-29 02:30 +02:00

Our engine skips the nonexistent time. Vixie cron and GitHub Actions instead run it at 03:00. Neither approach is wrong, but you should know which one your scheduler uses.

4. Midnight jobs across a 25-hour day

0 0 * * * in New York runs at 2026-11-01 00:00 −04:00, then at 2026-11-02 00:00 −05:00. The gap between those runs is 25 hours. If you check for a daily job with a "has it run in the last 24h?" alarm, that alarm will fire falsely on 2 November.

How to protect yourself before Sunday

1. Use UTC where you can. Set CRON_TZ=UTC, set Kubernetes timeZone: Etc/UTC, or leave the GitHub timezone: key out.
2. Move local-time jobs out of 01:00–03:00. That window covers both EU and US transitions.
3. Make jobs idempotent. For example, take a lock or check "already ran for date X".
4. Preview the actual runs. The cron timezone page lists the next runs with their UTC offsets for unix, Quartz, AWS and GitHub syntax.
5. Monitor with schedule-aware heartbeats. A monitor that knows the cron expression and timezone expects the 25-hour day, so it won't send a false alarm. Cron Heartbeat is mine. Healthchecks.io and Cronitor also do this.

Have you been hit by a DST double-run? Tell me which scheduler it was in the comments. I'm collecting cases.

• a deploy overwrote the crontab;
• the container image has no cron daemon;
• GitHub disabled the scheduled workflow after 60 days without activity on a public repo;
• GitHub's schedule trigger started the run hours late, or dropped it under load (people reported 3–5 hour delays in September 2026);
• the server was rebooting at 02:00;
• DST: a 02:30 job doesn't exist on spring-forward day in most schedulers. On fall-back day, Kubernetes CronJob can run it twice.

Nothing errors in any of these cases, so nothing alerts. You find out when someone asks where last week's report went.

Invert the signal: heartbeats

A heartbeat ("dead man's switch") flips the logic. The job reports success, and silence triggers the alert.

0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://monitor.example/ping/SECRET

The monitor knows the schedule. If no ping arrives by next scheduled time + grace, it alerts you, and it alerts again when the job recovers.

Four details that decide whether it works

1. Use the real schedule, not "every 24 h". A weekday job checked as "every 24 h" false-alarms every Monday morning. A job in Europe/Berlin checked in UTC is an hour off for half the year. The monitor should evaluate the same cron expression in the same timezone.

2. Grace = the longest normal runtime + margin. For GitHub Actions, start at one hour. Late scheduled runs are normal there, and a monitor that cries wolf gets muted.

3. Report failures explicitly so you don't wait for the deadline:

   job.sh && curl -fsS .../ping/SECRET || curl -fsS .../ping/SECRET/fail
   

4. Never let monitoring break the job. Add || true around pings in scripts, and keep the ping URL secret (it's a capability).

GitHub Actions specifically

on:
  schedule:
    - cron: "17 6 * * 1-5"         # avoid :00, the busiest minute
      timezone: "America/Chicago"   # supported since March 2026
  workflow_dispatch:
jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - run: ./make-report.sh
      - name: Heartbeat
        if: success()
        run: curl -fsS -m 10 --retry 3 "${{ secrets.HEARTBEAT_URL }}"
      - name: Report failure
        if: failure()
        run: curl -fsS -m 10 "${{ secrets.HEARTBEAT_URL }}/fail"

If the job must run at an exact time, add an external clock that calls workflow_dispatch, and make the workflow check "already done today?" first. The heartbeat then tells you if both paths failed.

Also verify the result

A backup that "succeeds" with a 40-byte file passes every exit-code check. Before pinging, check the artifact (gzip -t, size versus yesterday, a row count). The ping then means "a good backup exists", not just "a script ran".

Tools

• Healthchecks.io: open source, self-hostable, 20 free checks, email and lots of integrations. If you're unsure, start here.
• Cronitor, Dead Man's Snitch, Better Stack: hosted, polished dashboards.
• Cron Heartbeat Monitor. Disclosure: I built this one. It's a small API-first option that natively understands Unix, Quartz, AWS EventBridge and GitHub Actions schedules (including timezone:), applies a 1-hour default grace to GitHub checks, and sends webhook alerts compatible with Slack and Discord. 5 checks are free and 100 checks cost $5/month. It has no email, SMS or dashboard, and it's best-effort with no SLA. Docs: https://cron-heartbeat.vendorpapers.workers.dev/docs

If you just want to sanity-check an expression or see how a schedule behaves across this weekend's DST change (EU 25 Oct, US 1 Nov), there's a free checker with per-timezone next runs: https://cron-toolkit.vendorpapers.workers.dev/cron-timezone

Checklist version of this post: https://cron-toolkit.vendorpapers.workers.dev/monitor-cron-jobs

"Cron" means at least four different formats. When you move a job from Spring/Quartz or AWS EventBridge to a crontab, a Kubernetes CronJob or GitHub Actions, these are the differences that break things quietly.

1. Field count: seconds and year

To convert Quartz to Unix, drop the seconds field. That only works if seconds is 0; Unix cron can't run more often than once a minute.

2. ? is mandatory in Quartz and AWS, and invalid in Unix

Quartz and AWS require ? in either day-of-month or day-of-week. Unix uses *.

Quartz: 0 0/30 8-18 ? * MON-FRI
Unix:   0,30 8-18 * * 1-5

3. Day-of-week numbering is shifted

Unix: 0=Sunday (and 7 too). Quartz and AWS: 1=Sunday, 7=Saturday. So Quartz ? * 1 is Unix * * 0. Copying the number unchanged moves your job to a different day. Use MON-SUN names wherever the target format accepts them.

4. Timezones

• Crontab uses the server's timezone (or CRON_TZ, where supported).
• GitHub Actions schedule: is always UTC, and it won't run jobs more often than every 5 minutes.
• EventBridge Rules run in UTC. EventBridge Scheduler accepts a timezone.
• K8s CronJob has spec.timeZone (1.27+).

A 0 9 * * 1-5 meant for 9 AM Chicago fires at 3 or 4 AM Chicago on GitHub, depending on DST.

Worked examples

Quartz L, W and # (last day, nearest weekday, nth weekday) have no Unix equivalent. You need a wrapper script that checks the date, or a scheduler that supports them.

Check before you deploy

Always list the next few run times in the timezone the scheduler actually uses. It catches all four traps above.

Free browser tools (no signup): Quartz → Unix · AWS → Unix · GitHub Actions checker · cron to English. If you need this in code (CI linting, admin UIs), there's an API with a free 1,000-calls/month plan: Cron Toolkit on RapidAPI. It doesn't support L/W/# yet either.