Performance Glossary
Cron job — Cron: Taking Work Off the Visitor's Request
Scheduled posts publish late, the nightly export sometimes does not run, and both symptoms point at the same misunderstanding about WordPress cron.
The short answer
A cron job pairs a command with a timetable and the server runs it on that timetable, on the system clock, whether or not a single visitor arrives — which is the property that WordPress's own scheduler does not have.
WP-Cron only fires when someone loads a page. On a busy site that is close enough to a timer; on a quiet one it means scheduled posts publish hours late and housekeeping simply does not happen.
By the HostingFast team · Reviewed 24 August 2026
0
Terms, measured not asserted
100+
Entries wired together
Real
Runnable commands
Free
Free to read, always
Five fields describe the timing: minute, hour, day of month, month and weekday. Between them they express everything from every minute to one morning a year, and each entry pairs that pattern with exactly one command line.
The standard WordPress fix is two steps: set DISABLE_WP_CRON to true so page loads stop triggering the scheduler, then add a real cron entry that calls wp cron event run --due-now every few minutes. Do only the first half and nothing runs at all.
Taking the work off the request
The reason to move a job to system cron is not tidiness, it is response time. Anything triggered by a page load happens inside somebody's request, occupying a PHP worker and adding to their time to first byte — and by design it lands on whichever unlucky visitor arrives first.
Move it to the server clock and the cost moves with it. The visitor gets a page; the export, the import and the queue drain happen on their own schedule, in a process nobody is waiting on.
Choosing the hour deliberately
A heavy job during your busiest hour competes for the same workers and the same database as your visitors. Read your traffic by hour before you pick a time, then put demanding work in the trough rather than at whatever o'clock the tutorial suggested.
Frequency deserves the same scrutiny. A five-minute schedule for a job that only needs to run nightly costs you 288 executions a day, each with its own PHP boot. Nothing about the result improves; the load is entirely gratuitous.
Proving it ran, and what it said
Redirect output to a log file rather than letting cron email it into the void: append both stdout and stderr to a dated file and you have a record you can grep. Silent success and silent failure look identical, and only one of them is acceptable.
Better still, have the job touch a file on completion and check that file's timestamp from a monitor. A cron entry that stopped firing three weeks ago is the classic quiet failure, because nothing reports the absence of an event.
Testing the command before scheduling it
Run the exact line over SSH first. Cron uses a minimal environment with a short PATH and a different working directory, so a command that works interactively can fail on schedule for reasons that have nothing to do with the timing fields.
Use absolute paths for the binary and for every file the job touches. That single habit removes most cron failures, and the ones it does not remove will be in the log you set up in the previous step.
Automation with the verification attached
Every scheduled job in these entries comes with the way you find out it ran. Automation without a record is just a thing you hope is happening.
SSH on the developer plans means you can test the command interactively first, and the panel lists every entry so an audit takes a minute.
- Work moved off the request path
- Timing chosen from your own traffic
- Output logged, not emailed away
- Absolute paths as standard
Why HostingFast
Standard on every plan
Load moved, not just hidden
Why a scheduled job on the server clock costs a visitor nothing while a page-triggered one costs them the whole task.
The WordPress fix in full
Both halves of the WP-Cron change, in order, so the site does not end up with no scheduler at all.
Timing from your traffic
Picking the hour from your own by-hour figures rather than from whatever the tutorial happened to use.
Evidence that it ran
Logging and a timestamp check, because a silent success and a silent failure are indistinguishable.
Environment traps up front
The short PATH and different working directory that break commands which worked perfectly in your shell.
Auditable by design
How to keep the entry list short enough that reading it occasionally is realistic maintenance.
Quick Start
From order to online
- 1
Run the command interactively first
Execute the exact line over SSH. If it fails there it will fail on schedule, and you will find out far more quickly.
- 2
Pick the hour from your traffic data
Check requests by hour, then place heavy work in the trough. A nightly export in your peak hour is a self-inflicted slowdown.
- 3
Append output to a dated log
Capture stdout and stderr to a file you can grep. Then check the timestamp weekly, because a stopped job announces nothing.
Built In
Loaded onto every plan
- SSH, Git and Composer on the developer-focused plans
- Daily backups with a self-service restore you run yourself from the panel
- PHP version selectable per site, switched from the control panel in seconds
- NVMe on every tier — the entry plan runs the same drives as the top one
- LiteSpeed compiled into the server, not a caching plugin bolted on afterwards
- cPanel, so every script and tutorial you already have still applies
- Staging you can clone, break and throw away before anything reaches live
- 99.9% uptime as the target, monitored around the clock
- A human on support at any hour, including for the awkward questions
- Renewal billed at your signup rate — no year-two step change
Frequently Asked
What people ask us most often
How often should the system cron call WP-Cron?
Every five minutes suits most sites: frequent enough that scheduled posts publish close to their time, rare enough that you are not booting PHP constantly for nothing. Sites with time-sensitive queues sometimes go to every minute, and sites with nothing scheduled can go far longer.
Why does my job work in the shell and fail on the schedule?
Because cron runs with a minimal environment: a short PATH, a different working directory and none of your shell profile. Use the absolute path to the binary, absolute paths for any files, and redirect the output somewhere you can read the error it is currently producing.
What does support actually cover at three in the morning?
A human reply at any hour, with a scope that includes the practical jobs: DNS records, mailbox setup, a restore, a WordPress site that has stopped answering. Send a hard technical question in before you buy — the reply you get is a fair preview of the standard afterwards.
Does the price move at renewal?
No. You renew at the rate you ordered at, every term, because there is no introductory teaser price to fall off. Every invoice sits in your client area and auto-renewal is a toggle in the account rather than a phone call to somebody's retention desk.
Keep reading
WordPress
The PHP application under four in ten websites, and what decides its speed.
SSH (Secure Shell)
An encrypted shell into the server, and the WP-CLI work that depends on it.
How to Set Up a Cron Job
The five timing fields, the command line, and how to see that it ran.
WordPress Hosting
WordPress with LiteSpeed caching, staging and updates handled for you.
Domain Names
Register or transfer a name, with year one included on annual hosting orders.
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.
Let the clock do it, not the visitor.
SSH and WP-CLI on developer plans, cron in the panel, and LiteSpeed keeping cached pages off the worker pool entirely.
View WordPress Hosting plans