Scheduling Jobs with cron and Timers

Cron syntax

┌ minute (0-59)
│ ┌ hour (0-23)
│ │ ┌ day of month (1-31)
│ │ │ ┌ month (1-12)
│ │ │ │ ┌ day of week (0-6, Sunday = 0)
│ │ │ │ │
30 2 * * *  /usr/local/bin/pg-backup.sh

Edit your jobs with crontab -e; list them with crontab -l. Use the Cron Parser in Dev Tools to check an expression before you rely on it.

The three cron pitfalls

1. A minimal environment. Cron does not load your .bashrc, so PATH is short and your variables are missing. Use full paths and load config explicitly.
2. Silent failures. Output goes to local mail nobody reads. Redirect it to a log.
3. Overlapping runs. A slow job can still be running when the next one starts.

A robust entry that solves all three:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
30 2 * * * flock -n /tmp/backup.lock /usr/local/bin/pg-backup.sh >> /var/log/backup.log 2>&1

flock -n skips the run if the previous one still holds the lock.

Know when a job did not run

A failed job is visible; a job that silently stopped running is not. Use a dead man's switch such as Healthchecks.io or Better Stack heartbeats: the script pings a URL at the end, and you are alerted if the ping does not arrive on time.

/usr/local/bin/pg-backup.sh && curl -fsS -m 10 --retry 3 https://hc-ping.com/your-uuid > /dev/null

Timers instead of cron

On systemd servers, timers (see Linux System Administration) give you journalctl logs per run, Persistent=true catch-up after downtime and resource limits. Prefer them for important jobs.

Scheduling in the cloud

On platforms like Render, use Cron Jobs as a separate service with the same code and env vars as your app. Keep scheduled work out of web workers, which can be restarted or scaled at any time.

Exercise

Schedule your disk-alert script to run every 15 minutes with flock, logging to a file, and a heartbeat ping on success.