Timer Command in Linux: How to Schedule Tasks Like a Pro
If you’ve ever tried to get a script to run at 3 a.m. and ended up staring at your terminal all night, this one‑liner will save you from that headache.
What the timer command actually is
There isn’t a single “timer” binary in most distros; the concept lives inside cron, systemd timers, or ad‑hoc tools like watch and sleep. The goal, however, is the same: tell Linux to fire a program at a specific time or after a delay.
Scenario: A broken backup script that only runs once every few weeks
I once had a friend who set up a nightly database dump using at. The first week worked fine, but the next week it stopped because they forgot to keep the system awake past midnight. A proper timer solves that.
1. Cron – “the old‑school” way
Cron lives in /etc/crontab and user crontabs under /var/spool/cron.
The syntax is:
# minute hour day month weekday command 15 2 * /usr/local/bin/backup.sh
Why it matters: Cron runs as a background daemon, so your script doesn’t need to stay in the foreground. It’s perfect for regular jobs (daily, weekly, etc.) and works on every Linux distribution.
2. at – one‑shot timers
If you just want something to happen once, at is handy:
echo "/usr/local/bin/cleanup.sh" | at 23:45 tomorrow
Why it matters: at doesn’t require a cron entry, and the job disappears after execution. It’s great for quick, ad‑hoc tasks like “run this script when I’m home.”
3. systemd timers – the modern replacement
Most recent distros ship with systemd, which lets you pair a service unit (what to run) with a timer unit (when to run).
1. Create a service file /etc/systemd/system/cleanup.service:
[Unit] Description=Cleanup temporary files [Service] ExecStart=/usr/local/bin/cleanup.sh
2. Create a timer file /etc/systemd/system/cleanup.timer:
[Unit] Description=Run cleanup daily [Timer] OnCalendar=daily # or OnCalendar=--* 02:00:00 for 2 a.m. Persistent=true # fire missed events when the system wakes up [Install] WantedBy=timers.target
3. Enable and start:
sudo systemctl enable --now cleanup.timer
4. Check status:
systemctl list-timers --all | grep cleanup
Why it matters: Systemd timers integrate with the rest of systemd (logging, dependencies). They’re more reliable than cron on systems that sleep or hibernate because they can “catch up” when the machine comes back online.
4. watch – quick and dirty
If you need a script to run every minute while you stare at the terminal:
watch -n 60 /usr/local/bin/check_status.sh
Why it matters: watch is great for debugging or monitoring, not for scheduled jobs that survive reboots.
5. sleep – pause in a shell script
Sometimes you just need a delay inside a script:
#!/bin/bash echo "Backing up now" # do backup stuff sleep 3600 # wait an hour before next step
Why it matters: sleep is built‑in, no external daemon needed. It’s useful for scripts that perform actions in stages with a time gap.
Common pitfalls
- Using watch to schedule something permanent: Watch never writes to disk; if you kill the terminal, the job stops.
- Assuming at works across reboots: It doesn’t. Use cron or systemd timers instead.
- Relying on crontab without logging: By default, cron emails output to the user. If your mail isn’t set up, you’ll lose all logs.
Quick cheat sheet
| Tool | Best For | Command |
|---|---|---|
| cron | Recurring jobs (daily, weekly) | crontab -e |
| at | One‑time job at a specific time | echo cmd at 14:30 |
| systemd timer | Modern, reliable recurring with dependencies | systemctl enable --now mytimer.timer |
| watch | Live monitoring while you’re in the terminal | watch -n 60 ./script.sh |
| sleep | Pause inside a script | sleep 300 |
Wrap‑up
You don’t need a mysterious “timer” binary to get Linux running tasks on time. Pick the right tool for your job, know its quirks, and you’ll keep scripts firing when you expect them to.
That’s all folks—go schedule like a pro!
