There's a category of hosting features almost nobody uses until the day they urgently need it: scheduled tasks, better known by their technical name, cron jobs. They let the server run something on its own, at a fixed time, without you being there. It would sound like a minor detail if it weren't for the fact that automatic backups, scheduled email sends, temporary file cleanup, and price synchronization for many online stores all depend on them.
What a cron job is, without jargon
Picture an alarm clock inside the server. You tell it "every day at 3 in the morning, run this file," and the server does it, whether or not you have visitors, whether or not your computer is on. That's the whole idea. The task can be a PHP script, a system command, or a call to a web address.
The schedule is expressed with five fields defining minute, hour, day of month, month and day of week. In cPanel you don't need to memorize that syntax: there's a dropdown with common options like "once an hour," "once a day," or "once a week." For 90% of cases, that's plenty.
What it's used for in real life
- Your own backups. On top of the provider's backup, many people prefer generating their own copy and shipping it elsewhere. A daily cron that compresses the site folder and exports the database handles that.
- Automatic cleanup. Deleting temporary files, old logs, expired sessions, and exports left lying around. Without this, disk space fills up on its own over time.
- Scheduled email sends. Newsletters, abandoned cart reminders, expiration notices. Anything that has to go out at a fixed time.
- Syncing with external systems. Updating stock and prices from your management software, importing a catalog, exporting orders to accounting.
- Automatic reports. A daily summary of sales or errors landing in your inbox without you having to go look.
- Homemade monitoring. A script that checks the site responds and alerts you when something fails.
The WordPress cron problem
Here's something worth understanding because it affects an enormous number of sites. WordPress has its own scheduled task system, but it isn't a real cron: it isn't triggered by a server clock, it's triggered by visits. Every time someone opens your site, WordPress checks whether there are pending tasks and runs them right then.
That creates two opposite problems. If your site has few visitors, tasks run late or never run at all: you scheduled a mailing for 9 in the morning and it goes out at 2 in the afternoon, when the first visitor showed up. And if your site has lots of visitors, the opposite happens: WordPress checks the task list on every single page load, adding unnecessary work and making everything slower.
The standard fix is disabling the internal WordPress cron and replacing it with a real server cron that calls it every 15 minutes. You disable it with one line in the WordPress configuration file and create the task in cPanel pointing at the corresponding file. The result is twofold: tasks run on time, and the site stops carrying that weight on every visit.
Common mistakes when setting up scheduled tasks
- Scheduling everything at the same time. If you set five heavy tasks for exactly 3:00, they collide and saturate the account. Stagger them: 3:00, 3:15, 3:30.
- Running every minute without needing to. It's the fastest way to burn resources and get a warning from your provider. Ask yourself honestly how often you actually need that task.
- Not controlling the output. By default, each run may email you. If the task runs every 5 minutes, that's nearly 300 emails a day. Redirect the output to avoid it, keeping only errors.
- Using relative paths. Cron doesn't run from the directory you think it does. Always use full absolute paths.
- Leaving no log. A task that fails silently is worse than not having it. Have it write to a log file recording what it did and when.
- Tasks without a time limit. If a script hangs and the next one starts anyway, you end up with twenty copies running at once. A simple lock file prevents that.
How to verify it works before trusting it
The most expensive mistake is assuming the task runs because you created it. Before calling it done, do this: schedule it five minutes from now, wait, and verify it did what it was supposed to do. Only then set the final schedule. And once a month, check the log: it's astonishingly common to find tasks that stopped working months ago because a path or a password changed, and nobody noticed because nobody was looking.
How often each task should run
A very common question is how frequently to schedule each thing. The practical rule is to ask how long the business can tolerate that data being out of date. If your store syncs stock with a management system and you sell ten products a day, hourly is more than enough. If you sell hundreds and there's a real risk of selling something you don't have, then dropping to every fifteen minutes makes sense. Temporary file cleanup can be weekly without anyone noticing, while the WordPress cron trigger is best set to every five or fifteen minutes so scheduled mailings actually go out on time.
A complementary criterion is the cost of the task itself. A lightweight query can run often without bothering anyone; a process that walks the entire database and produces a multi-gigabyte compressed file shouldn't run more than once a day, and always during your quietest hours, typically between 2 and 5 in the morning in the time zone where your audience lives. Scheduling it at noon is the fastest way to have visitors notice the site got slow without understanding why.
What to check in your hosting
Not every plan treats scheduled tasks the same. The points to verify are: how many simultaneous tasks the plan allows, the minimum frequency permitted (some won't go below 15 minutes), whether there's a maximum execution time that could cut off your long-running processes, and whether the panel lets you view and edit them comfortably. cPanel handles all of this well with a simple interface, one of the reasons it remains the most widely used control panel in the world.
If you're evaluating where to host a project that needs automation, BanaHosting covers all of the above: full cPanel with a cron job manager, per-account selectable PHP versions, and generous resources starting from the $4.95 a month entry plan, with 50 to 150 GB of SSD depending on the tier. It also includes automatic daily backups with JetBackup, so you don't even need to schedule your own copy to be covered, though having a second one for peace of mind is always a good idea.