./ahmedhashim

Systemd Timers vs. Cron Jobs

I needed to schedule a task on a Linux VM: send a POST request to a local webserver with an auth header. Cron could have done it, but a systemd timer ended up being the cleaner choice.

Cron Jobs

Cron runs commands in isolation. It doesn’t know whether the service you’re calling is up, whether your environment variables exist, or where logs should go. You can make it behave, but you’re usually stitching together environment sourcing, dependency checks, and log redirection.

Timezones are another sore spot: cron uses the system’s local time, so a job set for 0 6 \* \* TUE will silently shift when daylight savings flips unless you manually convert and adjust. In edge cases, jobs scheduled during the skipped hour never run at all.

Here’s what my task looks like as a cron job:

# This runs 6am PT… except when DST starts or ends.
0 6 * * TUE curl http://localhost:8080/task

Systemd Timers

Systemd timers avoid all of this. A timer triggers a service, and that service behaves like everything else systemd manages: explicit dependencies, predictable environments, centralized logs, and consistent scheduling. If you want UTC, you declare UTC in the timer definition. No DST drift or surprises.

Here’s the same task using systemd:

# /etc/systemd/system/weekly-task.service
[Unit]
Description=Send scheduled POST request
After=local-web.service
Requires=local-web.service

[Service]
Type=oneshot
EnvironmentFile=/etc/secrets/env
ExecStart=/usr/bin/curl -X POST \
  -H "X-Auth-Token: ${TOKEN}" \
  http://localhost:8080/task

And the timer:

# /etc/systemd/system/weekly-task.timer
[Unit]
Description=Run weekly task every Tuesday at 14:00 UTC

[Timer]
OnCalendar=Tue 14:00 UTC
Persistent=true

[Install]
WantedBy=timers.target

The timer only schedules the work, and the service defines the real behavior. Requires and After ensure the webserver is online before the request runs, and any secrets can be pulled in through an environment file.

Stability

When the clocks change, cron doesn’t warn you. Your “6am” task suddenly runs at 5am or 7am depending on the direction of the shift. Systemd, by contrast, treats Tue 14:00 UTC as an absolute, stable moment in time.

Cron is still fine for quick one-liners, but timers integrate into the system’s lifecycle in a way that feels sturdier.