How to Check If Your Linux Cron Jobs Are Actually Running

AV Services · avservices.in · Linux Infrastructure, Mumbai · Since 1999

The MD of a logistics company in Andheri called me on a Friday afternoon.

Not panicking. Just confused. His IT person had left 3 months ago and he had hired a freelancer to keep an eye on things. The freelancer had set up a cron job to back up the MySQL database every night at 2am. Job was running. No complaints.

He wanted me to do a quick check before onboarding as a retainer client.

I logged in. Pulled the cron log. The job had last run successfully on the 14th. It was the 28th.

The freelancer had not set up log rotation. The cron job was still firing — but writing to a log file that had hit the disk limit 2 weeks ago. When the log filled up, the job started failing silently. No alert. No email. No red flag anywhere.

14 days of missing backups. Nobody knew.

Cron jobs do not call you when they stop working. They just stop. And unless someone checks, you find out the hard way — usually when you need the backup most.

Most business owners assume their IT person is checking. Most IT people assume the green status in the scheduler means everything is fine. Neither is wrong exactly. They are just not asking the right question.

The right question: when did this job last actually complete successfully, and how do I know?

Here is what I check on every server audit.

First, the cron log. On most Linux servers it is at /var/log/syslog or /var/log/cron. A quick grep shows every execution:

grep CRON /var/log/syslog | tail -20

This tells you the job ran. It does not tell you the job succeeded.

Second, the output. If your cron job is not redirecting output somewhere, you have no record of what it actually did. Every cron job should write to a log file:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

That 2>&1 captures errors too. Without it, errors vanish.

Third, the timestamp on the output file. If your backup creates a file, check when it was last modified:

ls -lh /backup/latest/

If it is 2 weeks old and the job supposedly runs nightly, something broke 2 weeks ago.

Three checks. Five minutes. Most servers I audit have never had any of them done.

The logistics company is on a retainer now. We run these checks monthly, plus automated alerts if a backup file has not been updated within 25 hours. The freelancer was not careless — he set it up and moved on. Nobody asked him to verify it.

That is the gap a retainer fills. Someone who comes back every month and asks: did this actually work?

AV Services manages Linux servers on monthly retainer for businesses in Mumbai and across India. Every retainer includes monthly cron job verification and backup restore testing. If you want someone to check whether your scheduled jobs are actually doing what you think, start with a free 30-minute audit call — no access needed, no commitment.