Cron vs systemd timers

Cron and systemd timers are two ways to run a job on a schedule. Cron uses lines in a crontab file. systemd timers use unit files with calendar events. Both work well on a VPS when you pick one owner for each job and stick to it. Running the same task in both places is how you double-send mail, hit a payment API twice, or overload WordPress with overlapping wp-cron traffic.

On shared hosting you only get cPanel cron. You do not control systemd there, so the panel is your scheduler. On a VPS you have root and can use either tool. Decide which one owns the job, put the schedule there, remove the other copies, and watch one full cycle before you move on.

How to pick one scheduler and stick to it

Name the job and the single place that will fire it. If WordPress is involved and you are moving the schedule into crontab, disable the built-in runner in wp-config.php. Remove any leftover timer or old @daily line in the same change, not later in the week. Send output to a log you can read, or to mail you actually check. Wait for one run and confirm it fired once.

1. Name the job and the one scheduler that will fire it.
2. Disable wp-cron in wp-config.php if WordPress is in the picture and you are moving the schedule to crontab.
3. Remove any duplicate timer or leftover @daily line.
4. Redirect output to a log, or to mail you actually read.
5. Wait for one run. Confirm it ran once.

systemctl list-timers –all | head

That list shows every timer systemd knows, including idle ones. The NEXT and LAST columns tell you whether the calendar event is doing what you expect. If your job is missing from this list and missing from crontab -l for the user you expect, it is not scheduled. If it appears in both places, it is scheduled twice.

Mail, logs, and avoiding stampedes

Cron mails stdout and stderr to the user unless you redirect them. That mail is useful when a job fails, and noisy when a script prints on every run. Redirect to a file under /var/log and rotate it. Timers write to the journal for the matching service unit, so journalctl -u thatjob.service is the usual place to look.

cPanel cron in the panel is still cron. It runs as the account user with that user’s environment, which is thinner than an interactive SSH shell. Set PATH in the crontab if the job calls binaries you take for granted at the prompt. Do not add a systemd timer on shared hosting. You do not own systemd on those accounts.

WordPress and three clocks at once

WordPress sites often end up with three schedules at once: the default wp-cron.php spawn on page views, a cPanel cron line added later, and a third-party monitor hitting the same URL. That path causes stampedes and odd timing bugs. Keep one schedule and one log. If you move a job from crontab onto a timer, delete the crontab line in the same change so nothing races the next cycle.