How do I check my crontab?

Paste it here and read the result line by line. The checker turns every schedule into a sentence such as Every Monday at 09:00, computes the next run in your timezone, and marks the lines that do not do what they appear to do. On the server itself, crontab -l prints the file and crontab -e opens it for editing, but neither of them tells you whether the schedule means what you intended.

What timezone does crontab use?

The system timezone by default, not UTC and not yours. That is the most common reason a job appears to run hours late. A line reading CRON_TZ=Europe/Berlin at the top of the file changes it, but only for the lines below it. The checker reads that assignment and computes each line in the zone that actually applies to it, instead of treating the whole file as one zone.

Only if the server runs in UTC, which is a convention rather than a rule. cron follows the machine's own timezone, so the same file behaves differently on a host set to Europe/Berlin and one set to UTC. Many teams standardise on UTC precisely to remove the question, and to avoid the twice-yearly clock change that makes a job vanish in spring and run twice in autumn. The checker shows you which zone each line is actually being read in.

What path does cron use?

A very short one, usually just /usr/bin and /bin. cron does not read your shell configuration, so nothing from .bashrc, .profile or a version manager is available. A command that works when you type it can fail under cron for no other reason. The checker flags every command written without a full path that is not part of that base set, and suggests setting PATH at the top of the file.

Why is cron not executing my script?

Usually the PATH, the working directory or the percent sign. cron starts with a minimal environment and the home directory as its working directory, so relative paths break. An unescaped % in the command cuts the line short, because cron reads it as a newline and hands the rest to the job on standard input. And a script that is not executable, or whose interpreter line is missing, fails silently because the output goes to mail nobody reads. The checker catches the second and third of these from the text alone.

How to verify crontab is working?

Check the schedule here first, then the execution on the server. This tool tells you exactly when each line fires next, in the right timezone, which rules out the largest class of cron problems without touching anything. Whether the job actually ran is a server question: look at the cron log, at syslog, or redirect the job's output to a file so there is something to read afterwards.

Why should cron jobs not all start at the same time?

Because they then compete for the same processor, disk and database. The classic case is five lines all set to 0 0 * * *: at midnight everything starts together, the backup fights the reindex, and a run that normally takes two minutes takes twenty. The checker compares the upcoming executions of every job and reports each instant that carries more than one, then offers to spread them across the hour.

Is my crontab uploaded when I check it?

No, the file stays in your browser. There is no upload, no server call and no storage. Splitting the lines, the timezone arithmetic and the collision scan all run locally, and the page keeps working offline once it has loaded. For a production crontab, which names hosts, paths, databases and occasionally a credential somebody put on a command line, that is not a detail.

Crontab checker: whole file, timezone, next run

What does the crontab checker do?

It takes what cron on your server actually reads: the whole file. Comment lines, blank lines, assignments such as CRON_TZ=, PATH= and MAILTO=, the schedule and the command behind it. None of that has to be stripped out first. Every line in becomes a line out: the schedule in plain words, the next run in the zone that applies to that particular line, and the notes that belong to it.

The checker runs entirely in your browser. No upload, no server, no cookie wall. With a crontab that is not a side issue, because the file names hosts, script paths, database names and now and then a password somebody typed onto a command line because it had to be quick.

Why is a single-expression checker not enough?

Because the interesting mistakes live between the lines. One expression can be looked up in seconds, and there are good tools for it. None of them answers the questions you actually have in front of an inherited crontab: is the same thing scheduled twice? Does the backup collide with the export? Does the CRON_TZ at the top still cover the line at the bottom? And why has no mail arrived since the server move?

Those are properties of the file, not of the expression. Copying a crontab into a single-line field one row at a time shows you every row in isolation, and therefore none of these questions. The checker turns the order around: the file first, then the line.

What happens when several jobs start on the same minute?

They share everything. Processor, disk, network and usually the same database. The classic case looks like this:

0 0 * * * /usr/local/bin/backup-db.sh
0 0 * * * /usr/local/bin/backup-files.sh
@daily    /usr/local/bin/rotate-logs.sh
0 0 * * 1 /usr/local/bin/weekly-report.sh
0 0 * * * /opt/app/bin/reindex.sh

Five lines, four of them daily, one weekly. On Monday at midnight all five start inside the same minute. On paper that is a schedule; in practice it is a load spike. And because @daily expands to nothing other than 0 0 * * *, skimming the file does not reveal the collision at all.

The checker computes the upcoming runs of every job and lays them side by side. When more than one job lands on the same instant, it says so, with the actual date, the line numbers involved and the worst offender where the most jobs start together. Because it compares when things run rather than how they are written, @daily against 0 0 * * * and the weekly job against the daily ones both show up.

How does the tool spread the start times out?

At the press of a button, without touching the rest of the file. The first job of each pile-up keeps its minute, the others move evenly across the hour. The five lines above become minute 0, 15, 35, 12 and 5, still at midnight, still on the same day, with the same command. Hour, day and month stay untouched.

The proposal then checks itself. The rewritten file is computed through again from scratch. If an instant is left where two jobs still coincide, they are moved further until nothing collides. Only then does the panel say it worked out. Lines whose minute field is a list or a step are not moved automatically, because shifting them would change their meaning; they are named individually for you to look at instead.

The result is the complete file, ready to copy, with every comment and assignment exactly where it was. It goes straight back into crontab -e.

Which timezone applies to a cron job?

The system’s, as long as nothing says otherwise. Not UTC, not the browser’s, and not the one the person who wrote the line had in mind. Getting that wrong gives you a job that is supposed to run at six and in fact runs at midnight, with no log entry hinting at it.

A line reading CRON_TZ=Europe/Berlin changes it, but only for the lines below. Put it in the middle of the file and the jobs above it keep running in the system zone. The checker implements exactly that: it remembers the most recent zone as it walks down the file and computes each line in it. Lines in a different zone carry that zone visibly, and the overview counts how many distinct zones a file contains. Two is nearly always an accident.

Then there is daylight saving. When the clock jumps forward, a job inside the skipped hour does not run at all. When it goes back, it runs twice. Both are documented behaviour rather than bugs, but hardly anybody knows it before the first duplicate billing run.

Why can cron not find my script?

Because cron starts in a different world from your login session. No .bashrc, no .profile, none of the environment your deployment sets, and a PATH that per crontab(5) is usually nothing but /usr/bin and /bin. Everything a version manager, a package manager or your own build put into /usr/local/bin or the home directory is out of reach.

The checker flags every command written without a path that is not part of that base set. tar and find get no note; a hand-written cleanup does. If a PATH= sits at the top of the file, the note stays quiet, because the condition is then met.

A second classic lives in the command itself: the percent sign. In a crontab % is not an ordinary character. cron cuts the line there and pushes the remainder to the job on standard input. tar -czf backup-%Y.tgz becomes tar -czf backup- and a file nobody goes looking for. A backslash in front fixes it. The checker finds the spot and counts the backslashes correctly, so an already escaped percent sign raises no false alarm.

Where does a cron job’s output go?

Into mail, unless you say otherwise. If a job produces output and it is not redirected, cron sends it to the owner of the crontab or to the address in MAILTO. On servers without working mail delivery it therefore vanishes, and nobody notices.

The checker separates three states, because their consequences differ sharply. No redirect and no MAILTO: every run sends mail. MAILTO="" set: the output is thrown away, error messages included. Redirected to > /dev/null 2>&1: everything quiet, but deliberately so. A lone 2>/dev/null does not count as a redirect, because it only silences the errors and leaves the actual output flowing, which is the exact opposite of what was intended.

What is the difference between crontab -l and /etc/crontab?

The user column. A personal crontab has five time fields and then the command directly. The system-wide files /etc/crontab and everything under /etc/cron.d insert a column with the user name the job should run as, between the schedule and the command.

Copying a line from one into the other produces a failure that stays silent. In a personal crontab root simply becomes the command, and cron tries to start a program called root. That is why you pick the kind of file at the top. In personal mode the checker points out a line that looks suspiciously like it still carries a user column.

What does this tool not check?

It cannot see your server. Whether a script exists, whether it is executable, whether the user has the rights and whether the service is running at all is nothing anybody can answer from here. The checker works with the text you paste and nothing else.

It does not watch executions either. If you want to know whether a job really ran last night, you need monitoring on the server, not a tool in a browser. And it does not stop one run from overtaking the next: a lock file in the script does that. Here you only get the note that a job starts often enough for it to happen.

For single expressions, for Quartz, for AWS EventBridge and for exporting to GitHub Actions or a Kubernetes CronJob there is the sibling tool, the cron expression builder. Checking a file belongs here. Building a line belongs there.

Tool