Crontab validator

A valid schedule can still report failed work as successful

In the synthetic example above, the semicolon allows curl to run after the backup command fails. A successful HTTP request can then hide the workload’s failure. Paste that example into Cron Doctor to inspect the finding and its source evidence. It is not a production-ready backup command.

For supported cases, the report can offer a correction preview that makes the success request conditional. Review the change before using it: conditional reporting alone does not add a failure signal, validate the backup, or preserve every exit-status requirement. For an implementation that keeps workload and reporting results separate, see the completion-reporting shell example.

What to inspect when a crontab job does not run

• Entry format: supply one active job in user-crontab format: five timing fields followed by the command. A system crontab includes a username column; this checker does not validate that execution identity.
• Environment and timezone: include the relevant assignments before the job. Supply the scheduler’s actual timezone, using CRON_TZ where your cron implementation supports it or the checker’s fallback. A preview cannot establish the host’s configuration.
• Runtime context: inspect the scheduler service, logs, executable paths, permissions, and working directory on the host. Your interactive shell is not proof that cron has the same environment.
• Output: an exit code of zero is only useful if the command checks the result you need. Validate backup integrity, report freshness, or completed sync work before sending a success signal.

Use your installed cron implementation’s documentation and native validation for a complete file. See the Cronie crontab reference. Unix cron, Quartz, and scheduler-specific formats are not interchangeable.