Ops Brief
Hosting with cron jobs — A schedule nobody has to remember, and can prove ran
Your nightly export is set to 2am, the site gets no traffic at 2am, and WordPress pseudo-cron only fires when somebody arrives — so it ran at 9:40 the next morning, if at all.
The short answer
Use hosting with real system cron on the account: Turbo at $4.66 a month gives you minute-level scheduling from cPanel, so database dumps, feed imports, cleanup routines and a dependable replacement for wp-cron become jobs you configure once and stop thinking about.
The single highest-value change is replacing WordPress pseudo-cron with a system entry. Define `DISABLE_WP_CRON` as true in wp-config.php, then add a cron entry that calls wp-cron.php on a fixed interval. Scheduled posts, subscription renewals and abandoned-basket emails stop depending on whether a visitor happened to load a page.
Below: writing the crontab line so it actually works, the overlap problem nobody plans for, and how to make a silent failure at 3am visible the following morning.
By the HostingFast team · Reviewed 24 August 2026
NVMe
Storage, every tier
Free
Domain, first year
99.9%
Uptime, monitored
Flat
Renewal pricing
Scheduling looks like the simplest thing on a hosting account and produces some of the most persistent bugs, because a cron job that fails does so quietly, at night, with nobody watching.
The three things that make scheduled work reliable are an accurate crontab line, protection against a job overlapping itself, and captured output. This page covers all three, with the exact syntax.
Retiring WordPress pseudo-cron
WP-Cron is not a scheduler; it is a queue checked on page load. On a busy site that is close enough to a schedule. On a quiet one it means your 2am job runs whenever the first visitor turns up, and on a very busy one it means the check runs on requests that should have been fast.
The replacement is two steps. Add `define('DISABLE_WP_CRON', true);` to wp-config.php, then create a cron entry that hits wp-cron.php on an interval — every five or fifteen minutes suits most sites. Now the queue is checked on a clock rather than on chance.
Verify it rather than assume it. After the change, schedule a post a few minutes ahead and watch it publish. If it does not, the crontab line is wrong, and the next section is why.
Writing the line so it actually runs
Five time fields then the command: minute, hour, day of month, month, day of week. `*/15 * * * *` is every fifteen minutes; `0 2 * * *` is 2am daily. cPanel's interface writes these for you, but knowing the fields means you can read what is there.
Use absolute paths for everything — the binary, the script and any output file. Cron runs with a minimal environment and none of your login shell's convenience, which is the single commonest reason a job that works interactively does nothing on a schedule.
Call the PHP command-line binary rather than fetching a URL where you have the choice. A CLI invocation is not subject to a web request timeout and does not consume an HTTP worker. Confirm which binary you are getting with `which php` and `php -v` over SSH, because the CLI version and the web version can differ.
Set the interval to what the job needs, not to every minute out of habit. On a shared allocation a one-minute job that takes ninety seconds is the fastest way to make every site on the account feel slow.
Overlap, which is the failure nobody plans for
A job scheduled every five minutes that occasionally takes seven produces two copies running at once, then three. Duplicate emails, half-written exports and a database lock are the usual symptoms.
Wrap the command in `flock` so a second copy cannot start while the first is running: `flock -n /home/user/tmp/job.lock /usr/bin/php /home/user/scripts/job.php`. If the lock is held, the new invocation exits immediately.
Then measure how long the job actually takes. Prefix it with `/usr/bin/time -v` for a run or two, or simply log a timestamp at the start and end. If the runtime is creeping toward the interval, either the interval or the job needs to change before it becomes an incident.
Making a silent failure visible
By default, cron mails output to the account. That is useful for a job that should normally print nothing, because then any message at all means something happened. Set the notification address in the panel and leave it on for jobs where silence is the expected state.
For chatty jobs, redirect instead: append stdout and stderr to a log file with `>> /home/user/logs/job.log 2>&1` and rotate it. Then `tail -f` that file over SSH when you need to watch a run live.
The check that catches everything else: confirm each job has produced output recently, not merely that it appears in the cron list. A job that has been failing since a PHP version change three weeks ago looks identical to a working one from the panel.
Turbo at $4.66 a month: 25 sites, 20 GB of NVMe, 1 TB of bandwidth, 1 core and 2 GB of RAM, 50 MySQL databases, cPanel with cron, full SSH with Git and Composer, and a renewal at the same $4.66.
Why the syntax is on this page
Most hosting pages about cron say the feature exists and stop. The feature existing has never been the problem — the problem is a job that runs from your shell and does nothing from the scheduler, which is a path and environment issue every time.
We are recommending our own plan and saying so. The commands above work on any cPanel host, and the desk here will help you read the log if a job is still refusing to fire.
- Real system cron with minute-level granularity
- PHP CLI, not a URL fetch with a web timeout
- flock, so a slow run cannot stack up
- Output captured, so a silent failure is visible
Why HostingFast
Standard on every plan
System cron, not an imitation
Minute-level scheduling on the account from cPanel, running on a clock rather than on whether a visitor happened to arrive.
The CLI binary available
Call PHP directly over SSH or from cron, so a long job is not bound by a web request timeout or an HTTP worker.
Room for a job to finish
Process limits sized for real work, so a nightly export or database dump completes rather than being cut off partway.
Output you can capture
Mail the result or redirect it to a log file you can tail over SSH. A job that fails silently is a job you do not have.
Per-site PHP for scheduled work
The branch a script runs on is set per site, so upgrading one site's cron does not change what the others execute.
Backups behind the scheduled work
Daily backups with panel restores, for the morning a cleanup job turns out to have been slightly too enthusiastic.
Prices Side by Side
Our numbers next to the big names
Typical intro and renewal pricing across the market, lined up against ours — including the renewal figure most comparison charts skip.
| Feature | HostingFastMost popular | Typical household-name host | Typical bargain host | Typical loss-leader deal |
|---|---|---|---|---|
| Starting price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Renewal price / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Cheapest plan renews at its sign-up price | ||||
| SSL as standard | ||||
| Migration done for you | ||||
| NVMe drives on the cheapest tier | ||||
| Daily backups from the first tier | ||||
| Real humans on support, 24/7 |
*Our number is the lowest-priced plan we sell on an annual term, pulled live from the same catalogue that powers our pricing page — it physically cannot fall out of date. The other three columns show the ranges shared hosts in each bracket typically advertise: introductory offers that mostly demand a one-to-four-year commitment, then jump once it expires. We no longer name rivals or print their prices, because a figure we cannot verify on the day you read it has no business on this page. Line us up against whichever host you are really weighing — and give the renewal row the hardest look.
Quick Start
From order to online
- 1
Disable WP-Cron and schedule it properly
`define('DISABLE_WP_CRON', true);` in wp-config, then a cron entry hitting wp-cron.php every five or fifteen minutes.
- 2
Use absolute paths for everything
Binary, script and log. Cron's environment is minimal, and this is the reason most jobs run in your shell but not on schedule.
- 3
Wrap it in flock
One line that prevents a slow run from being joined by the next one. Duplicate emails and locked tables start here.
- 4
Prove it ran, do not assume
Check the job has produced recent output. A job broken since a PHP change looks identical to a healthy one in the panel.
Built In
Loaded onto every plan
- People on the desk at every hour of every day
- Real system cron with minute-level scheduling from cPanel
- PHP command-line binary available over SSH and from cron
- LiteSpeed caching in the web server rather than added by plugin
- NVMe storage as the baseline build rather than a premium-tier upgrade
- Renewals charged at the order rate, year after year
- Mailboxes on your own domain, for capturing job output
- Floods filtered before they reach the server your site runs on
- In-place upgrades between tiers, with no migration to arrange
- WebP image conversion built in at no extra cost
- Your existing site moved across by our engineers, free of charge
Frequently Asked
What people ask us most often
How do I replace WP-Cron with a real scheduled job?
Add `define('DISABLE_WP_CRON', true);` to wp-config.php, then create a cron entry that calls wp-cron.php every five or fifteen minutes. Scheduled posts, renewals and queued emails then run on a clock instead of waiting for a visitor. Verify by scheduling a post a few minutes ahead and watching it publish.
My job runs fine from the shell but does nothing on schedule. Why?
Almost always paths or environment. Cron runs with a minimal environment, so use absolute paths for the binary, the script and any output file. Check which PHP you are actually getting with `which php` — the command-line binary and the web PHP can be different versions with different extensions.
What happens if a job takes longer than its interval?
Copies stack up, and you get duplicate emails, half-written exports and database locks. Wrap the command in `flock -n` against a lock file so a second invocation exits immediately if the first is still running, then measure the real runtime and adjust the interval before it becomes an incident.
How will I know a job failed overnight?
Only if you arranged to. Leave cron's mail notification on for jobs that should normally print nothing, so any message means something happened. For chatty jobs, append stdout and stderr to a log file and check it has recent entries — a job broken since a PHP change looks perfectly healthy in the panel's list.
Keep reading
White-Label Hosting
Running scheduled maintenance across client accounts, where a failed job is somebody else's business.
Hosting With Redis Object Caching
Cache warming is a common cron job, and this explains which pages it is worth warming at all.
How to Set Up a Cron Job
The panel screens and the crontab fields walked through, with a worked example you can copy.
Web Hosting
Sprint, Turbo and Nitro with cPanel, cron and full SSH, on NVMe behind a LiteSpeed cache.
Domain Names
Registration and DNS, including the records a scheduled job may need to reach a third-party endpoint.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Schedule it once. Forget it safely.
Turbo at $4.66 a month with real system cron, the PHP CLI on the path and SSH to read the logs when it matters.
View Web Hosting plans