Skip to main content

Cron Depends on timedatectl

Cron does not have its own clock. It schedules jobs using the system time and timezone. On systemd-based distros, timedatectl is the primary interface for viewing and changing those settings.

Quick Summary
  • If system time or timezone is wrong, cron runs at the wrong moment.
  • Time sync (NTP) keeps clocks stable.
  • Time changes can cause missed or duplicated runs.

Cron uses system local time​

Check the current clock, timezone, and NTP sync:

check-system-time-timezone-ntp.sh
timedatectl
date -Is

If the timezone is wrong, a job scheduled for 03:00 runs at the wrong hour.

Changing timezone changes cron interpretation​

Set a timezone:

set-timezone-example.sh
sudo timedatectl set-timezone Asia/Jakarta
timedatectl | sed -n '1,20p'

Cron will now interpret schedules in the new local time.

Example crontab line:

cron-3am-example.txt
0 3 * * * /usr/local/bin/nightly-job

If system time is wrong, cron is wrong​

If the system clock drifts or is manually changed, cron follows it.

Symptoms:

  • jobs run early/late
  • jobs appear to skip
  • logs show unexpected timestamps

NTP corrections and cron behavior​

NTP can step or slew time. Large time jumps can produce confusing cron behavior.

Check sync status:

check-ntp-sync.sh
timedatectl show -p NTPSynchronized -p NTP
warning

Do not manually change system time on production hosts without understanding the consequences. Time changes can break certificates, logs, backups, and scheduled jobs.

Debug checklist: "cron ran at the wrong time"​

  1. Confirm timezone and current time.
  2. Confirm which crontab is active (user vs root).
  3. Check cron logs/journald around the expected window.
  4. Check whether the host recently rebooted.
  5. Check for DST transitions if you use local time.
debug-cron-schedule-time.sh
timedatectl
sudo crontab -l || true
crontab -l || true

journalctl -u cron --since '24 hours ago' --no-pager | tail -n 200
  • Prefer UTC on servers unless you have a strong reason not to.
  • Keep NTP enabled.
  • Record time settings in runbooks.

Daylight Saving Time (DST) pitfalls​

If your server uses a timezone with DST:

  • a scheduled hour can happen twice (jobs may run twice)
  • a scheduled hour can be skipped (jobs may not run)

If you cannot accept that behavior:

  • run the server in UTC
  • or schedule outside the DST transition window

Can cron run in a different timezone?​

Cron typically interprets schedules in the system local timezone. Some cron implementations support setting a timezone per crontab via CRON_TZ or TZ.

Because support varies, confirm on your host:

check-cron-timezone-support.sh
man 5 crontab | sed -n '1,120p'

If you must execute in a different timezone and your cron does not support it, a robust workaround is:

  • keep the server in UTC
  • run the job frequently
  • and gate execution inside the script based on the timezone you care about

Safe pattern: schedule often, run conditionally​

Example: run a job every 5 minutes, but only execute the payload at the desired local time.

conditional-timezone-run-example.sh
#!/usr/bin/env bash
set -euo pipefail

# Example: run payload at 03:00 Asia/Jakarta
if [ "$(TZ=Asia/Jakarta date +%H:%M)" = "03:00" ]; then
  /usr/local/bin/nightly-job
fi

This is not always needed, but it avoids DST surprises.

Next steps​

  • Cron basics: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/11-automation-task-execution/cron.mdx