A cron job runs a command on a schedule. Setting one up in the panel is a form with five fields, covered in How to Set Up Cron Jobs in cPanel.
This article is about the part the form does not help with: what is worth running on a schedule, and how scheduled jobs fail on a normal hosting account.
What is worth automating
Anything you would otherwise do regularly and eventually forget.
Backups of files or a database to somewhere off the server.
Cleanup, old logs, temporary files, exports that accumulate until the disk is full.
Application tasks the software expects to run regularly: publishing scheduled content, sending queued mail, rebuilding a cache.
Fetching something. A price feed, a stock file, a report from another system.
What is not
Anything that needs a decision when it goes wrong.
A job that emails you when a supplier feed looks wrong is useful. One that silently imports whatever it downloaded is a way to corrupt your data on a schedule, and nobody notices for weeks, because it ran successfully every time.
The rule: automate the action, not the judgement.
The failure you will actually meet
Not a broken script. Silence.
A cron job that fails produces output, and that output is mailed to the account. On most hosting that mail goes to a mailbox nobody opens, so the job stops working and nothing tells you.
Weeks later somebody notices the backups are old.
Two fixes, and the second is better. Send the output to an address you read. Or have the job itself report when it fails: a message to somewhere you actually watch. There is more on making an alert arrive in How to Set Up and Read Uptime Monitoring.
The second failure: it never ran at all
Cron runs with almost no environment, so a command that works when you type it fails here with "command not found".
Use full paths for the interpreter, the script, and anything the script touches. A relative path inside the script has the same problem, because the job does not run from the directory you assumed.
Test by running the exact line from the terminal before scheduling it. There is more on getting a shell in cPanel Terminal and SSH Access.
Overlapping runs
A job scheduled every five minutes that occasionally takes six starts running alongside itself. Instances accumulate, and on shared hosting that reaches the account's process limit: at which point the website becomes unavailable, which is not obviously a cron problem.
Either schedule it far enough apart that overlap is impossible, or have the script check whether it is already running before it starts.
This matters sooner on shared hosting than people expect, because the ceiling is low. How to Monitor Your Hosting Resources explains seeing it.
Frequency: less than you think
Every-minute jobs are almost never necessary and are the usual cause of a resource complaint.
Ask what actually breaks if the job runs every fifteen minutes instead. On most tasks the answer is nothing, and the resource cost differs by a factor of fifteen.
Stagger them, too. Four jobs all set for midnight run simultaneously; the same four at five-minute intervals do not compete.
The timezone is the server's
A job set for 02:00 runs at two in the server's time, which may not be yours.
Check before scheduling anything that must happen at a particular local hour. A nightly job that actually runs mid-afternoon is a surprise you get once, and it is usually discovered through the load it causes rather than through the schedule.
Application schedulers are a separate thing
WordPress and similar systems have their own scheduler that runs on visits rather than on a clock. On a low-traffic site, tasks run late or not at all.
The standard fix is a real cron job calling it, with the visit-driven trigger disabled. There is more on the arrangement in WP-Cron: Why Scheduled Posts Do Not Publish.
The general point applies to any application: find out whether its scheduler is real or visit-driven before relying on it for anything that matters.
Know what is already scheduled
On an account you inherited, list the jobs before adding one.
Inherited accounts frequently carry a job nobody knows about. A nightly export to a system that no longer exists, a sync to a former supplier. Some are harmless and some are still sending data somewhere.
Read each command and decide deliberately whether it should still run. How to Audit a WordPress Site You Inherited walks through the wider audit.
Confirm the job can run before scheduling it
A scheduled task that has never been run by hand is a task nobody knows works.
/usr/local/bin/php /home/user/bin/task.php; echo "cikis: $?" which php; php -v | head -1
Run the exact command, including the full paths, from a shell before putting it in the schedule. An exit code other than zero means it failed, and that failure would have been silent on a schedule.
Use the same interpreter path the schedule will use. A script that works with the default and fails with the specific version is a common surprise, since the two are frequently different versions.
Capture the output somewhere
Suppressing the mail is right and it leaves nothing to read when something goes wrong.
0 3 * * * /usr/local/bin/php /home/user/bin/task.php >> /home/user/logs/task.log 2>&1 tail -20 ~/logs/task.log
Redirecting both ordinary output and errors to a file keeps the record without filling a mailbox.
Rotate that file or it becomes the reason the account fills. A job running every few minutes and writing a line each time produces a substantial file within a year.
Know when it last succeeded
The difference between a job that is working and one that stopped months ago is invisible without a marker.
0 3 * * * /path/task.sh >> ~/logs/task.log 2>&1 && date > ~/logs/task.last find ~/logs/task.last -mmin +1500 && echo "UYARI: is calismadi"
Writing a timestamp only on success turns the question into a file age, which monitoring can check without understanding what the job does.
That is the difference between noticing within a day and noticing when somebody asks why the report has not arrived since the spring.