Cron job not running: a checklist of causes

Work through the list from the top. The first four causes explain most cases.

1. Is the schedule what you think?

Paste the expression into the tool on the home page. Check the plain-English line and the next run times, in the time zone your server uses. A job at "9 AM" that runs at 9 AM UTC will look like it never ran at 9 AM in India. Warnings in the tool also catch the "either day" rule and expressions that can never match, such as 31 February.

2. Does the syntax pass?

Run crontab -T file (from the manual) to test the file without installing it. It stops at the first error. A common one is a missing field: the command then loses its first word.

3. Is the last line ended with a newline?

The cron manual says each entry must end with a newline. A last line ended by the end of the file makes cron treat the crontab as partly broken.

4. Do you have a percent sign?

An unescaped % ends the command, as the manual explains. Replace % by \% in every date format.

5. Does the command work without your terminal?

Use full paths. A job does not read your profile. Test it as a clean environment would see it: env -i /bin/sh -c '/full/path/to/script.sh' runs a command with an empty environment, and any "command not found" shows up at once.

6. Can the script be executed?

Check chmod +x script.sh and the first line of the script (#!/bin/sh or #!/usr/bin/env bash). A script that works as bash script.sh but not as ./script.sh has lost its execute permission or its first line.

7. Is the cron service running?

On most Linux systems the service is called cron or crond. Starting and checking it depends on the system, for example systemctl status cron. A container may have no cron at all, which is the commonest reason that jobs "never run" inside Docker images.

8. Is the user allowed?

The manual describes /etc/cron.allow and /etc/cron.deny. A user not allowed cannot install a crontab at all.

9. Did the clock skip it?

If the time never happened (a daylight saving gap), the manual says the job does not run. See the time zone guide.

10. Where did the output go?

Add >> /tmp/job.log 2>&1 to the line and read the file after the next run. Most "cron did nothing" cases show a clear error message there.

On GitHub Actions and Kubernetes

GitHub says scheduled workflows run only from the default branch, can be delayed at busy times (the top of every hour especially), and in a public repository are automatically disabled when there has been no repository activity for 60 days. Kubernetes says CronJob creation is approximate, that a missed Job may be skipped if startingDeadlineSeconds has passed, and that more than 100 missed schedules makes the controller log an event. See the two platform guides.

This is an independent guide and tool. It is not connected with crontab.guru, Quartz, GitHub, Kubernetes, Spring or the Linux projects named here. Product names belong to their owners.