Fix a Broken Server Cron Job

The Problem

A cron job that used to work has silently stopped, or one you just set up never ran at all — cron failures are notoriously silent unless you know exactly where to check.

About this problem

Cron is notoriously silent about failure — a job that stops running, or one that was just set up but never actually fires, produces no alert by default. The usual culprits are subtle: a path that only resolves in an interactive shell, a permission issue, or a syntax mistake in the schedule itself, none of which are obvious without checking in the right place.

This comes up when a task that used to run reliably has stopped (a report that's no longer generated, a backup that's stale), or a newly added cron job simply never seems to fire.

What's Included

• Checking cron syntax, timing and environment differences from an interactive shell
• Checking file/script permissions and paths used by the job
• Reviewing cron and application logs for the actual error
• Confirming the fixed job runs successfully on its next scheduled time

What's NOT Included

• Rewriting the underlying script's own logic (unless the bug is simple)
• Setting up new, unrelated cron jobs
• Ongoing monitoring of the job going forward

How It Works

1. Check the cron syntax and timing against what's actually intended — a simple schedule mistake is a common cause.
2. Compare the environment cron runs in against an interactive shell, since paths and variables often differ.
3. Check file and script permissions, and confirm the paths used in the cron command are absolute, not relative.
4. Review cron and application logs for the actual error message from the last run attempts.
5. Confirm the fixed job runs successfully on its next naturally scheduled time, not just when triggered manually.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

Why does my cron job work when I run it manually but not on schedule?

Cron runs with a much more minimal environment than an interactive shell — missing PATH variables or relative file paths are the most common reason a script behaves differently under cron.

How do I check if a cron job actually ran?

System cron logs (often /var/log/syslog or via journalctl) record whether cron attempted to run the job, which is the first thing to check before assuming it never fired at all.

Why did my cron job silently stop working?

Often an unrelated change — a file moved, a permission changed, a dependency updated — broke something cron depends on, with no error surfaced unless you're specifically looking at logs.

Can incorrect file permissions stop a cron job from running?

Yes, if the script or a file it needs isn't readable/executable by the user cron runs as, the job fails silently from cron's perspective even though the script itself is fine.

Does cron send an error notification if a job fails?

Not by default — cron can be configured to email output/errors, but this isn't automatic, which is exactly why broken jobs go unnoticed for so long.

How do I fix a cron job scheduling mistake?

Correcting the cron syntax (minute/hour/day/month/weekday fields) to match the intended schedule — a single misplaced value is a surprisingly common cause of jobs running at the wrong time or not at all.