How cron jobs work
Most sites never need this. Commands run as your site's user, from your home folder, with the same PHP as your site, and schedules are read in UTC with your own clock shown beside the server's.
To add one, see add a cron job.
The line that is already there
One crontab line is ours, labelled Ours. It pokes WordPress's own scheduler hourly, because left alone WordPress only runs scheduled tasks when a visitor loads a page — which means scheduled posts on a quiet site publish late or not at all.
Leave it in place.
The two traps the builder catches
An unescaped %. Cron treats the first one as a newline: it cuts your
command off there and feeds the rest to it as input. The line saves and never
works. Write \% instead — the screen spots it and offers the fix.
A line the panel would renumber underneath you is rejected rather than saved.
Before saving you see the exact line that will be written and when it would next run.
What this can’t do
There is no run history — no last run, exit status, duration or output. Everything on the screen is the schedule, never the result.
What to do: make the job report on itself. Append
>> $HOME/cron.log 2>&1 to the command and read the file
over SSH. Use $HOME, not ~ — cron's
shell may not expand the second at all.
There is no "run now" button.
What to do: run the command by hand over SSH. That shows you the output immediately instead of waiting for the next run.
You cannot pause a single line.
What to do: delete it and add it back later. Copy the command first.
Environment variables cannot be set in the crontab.
What to do: set them inside the command — VAR=value /usr/bin/php script.php
— and use full paths, because cron runs with a minimal environment.
Didn’t solve it?
Write to us with your Pressy’s address and what you were doing when it went wrong. Answered by the people who built it.
Last updated