Fleet Handbook
Hosting with cron jobs — The job that stops quietly is the one that costs you a client
Written for whoever is responsible when a client's nightly import stops running and nobody notices for three weeks.
Straight answer first
Run scheduled work as real system cron on cPanel accounts rather than trusting the scheduler inside the application, and route every job's output to an address you monitor — backups, imports, tidy-ups and a dependable replacement for wp-cron all become jobs you set once and can prove are still running.
The distinction that matters across a fleet is between a job that fails and a job that stops. A failure produces an error you can act on. A stopped job produces silence, and silence is discovered by a client noticing stale data weeks later, which is a considerably worse conversation.
Written by the Hosting Seller staff · Checked 24 August 2026
NVMe
Disk under every account
Free
Domain for the first year
99.9%
Uptime target we hold
Flat
Cost across the renewal
Cron is unglamorous and it is where a surprising amount of agency reputation is decided. Nightly database dumps, feed imports, report generation, cache warming, expired-data clearance — none of it is visible when it works and all of it is visible when it has not worked for a fortnight.
The scheduler built into WordPress compounds the problem because it fires on visitor traffic rather than on the clock. On a quiet client site it is quietest precisely when the job is due, which is why replacing it is the standard remedy for posts that publish late and queues that simply sit there.
Where the failure notice should land
On your address, not the client's. Cron output emailed to the account owner is the default arrangement and it is almost always wrong for a managed client, because it either goes to somebody who will ignore it or to somebody who will be alarmed by it.
Set the notification address deliberately when you create the job, and use one shared inbox rather than an individual's mailbox so that it survives staff changes. A cron alert going to somebody who left in March is functionally the same as no alert at all.
Then make silence detectable. A job that emits nothing when it succeeds cannot be distinguished from a job that has stopped, so either have it report success somewhere or check the log on a schedule. This is the single most common gap on an otherwise well-run fleet.
Replacing wp-cron across a fleet properly
The procedure is two lines: disable WP-Cron in wp-config, then add a system cron calling wp-cron.php every few minutes. Applied per site it is trivial; applied across twenty it needs to be a standard part of your provisioning rather than something somebody remembers.
Build it into the account template. Every new client site gets the same treatment at creation, so scheduled posts and queued work behave identically everywhere and you never have to reason about which sites were done.
Watch the interval on quiet sites. Every-minute polling on twenty low-traffic accounts is wasteful; every five or fifteen minutes is almost always sufficient and keeps the process count sensible on a shared arrangement.
Execution limits and the two o'clock collision
Everybody schedules at midnight or two in the morning, which means everybody's jobs collide. Stagger yours across the fleet — one client at ten past, another at twenty past — and the disk and CPU contention that produces mysterious partial failures largely disappears.
Check what the execution limits actually are before you build a job that needs ten minutes. A dump of a large client database, a feed import over a slow supplier API, or an image regeneration sweep are the jobs that discover the limit, and they discover it silently.
Where a job genuinely will not fit inside shared limits, that is a signal about the account rather than about cron. Move that client up a tier or onto their own resources rather than fighting the platform on their behalf every night.
Making it auditable for the client
Keep a list of every scheduled job across the fleet: which account, what it does, when it runs, where the output goes, and who asked for it. Jobs accumulate over years and the ones nobody can explain are the ones nobody dares to remove.
Put the important ones in the monthly note. 'Nightly backup and feed import verified' is a line a client understands, and it converts invisible work into evidence — which is what a retainer is actually paid for.
Review the list annually. Half of it will relate to a plugin that was removed, an integration that was retired, or a report nobody reads, and removing those is free performance and one less thing to explain.
Why this is a supplier's page
We sell the hosting this describes and we would rather say so than dress the recommendation up as neutral. The operational advice is portable; apply it to whoever you buy from.
Real system cron on the account, rather than an approximation of it, is a deliberate part of the catalogue because a fleet of client sites that cannot schedule reliably generates support work for both sides.
- Real system cron with minute-level scheduling
- Output captured or emailed to an address you choose
- Jobs staggered across accounts to avoid collisions
- Documented execution limits rather than discovered ones
Why Hosting Seller
On every plan, as standard
Alerts that reach you
The notification address is set per job, so a failure lands in your shared inbox rather than in a client's or a former colleague's.
Scheduling on the clock
Real system cron rather than a visitor-triggered scheduler, which is what makes a quiet client site behave the same as a busy one.
A provisioning standard
Building the wp-cron replacement into account creation means you never have to work out which sites were done.
Limits you can plan around
Knowing the execution limits before you write a ten-minute job is what stops a nightly dump failing silently.
Evidence for the monthly note
Verified backups and imports are a line a client understands, which turns invisible work into something they can see they bought.
A tier to move the heavy client to
When a job genuinely will not fit shared limits, the ladder continues rather than requiring a change of supplier.
Price Tags Compared
How we compare with the household names
Typical sign-up and renewal prices across the market, set next to ours — the second number most comparison charts leave off.
| Line item | Hosting SellerBest seller | Typical big-brand host | Typical budget host | Typical loss-leader |
|---|---|---|---|---|
| Entry price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Price at renewal / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Renewal price on the entry plan is unchanged | ||||
| SSL on every plan | ||||
| Site migration included | ||||
| The entry plan uses NVMe storage | ||||
| Entry plan gets a backup daily | ||||
| Live human support, 24/7 |
*The number in our column is the cheapest plan on our shelf, priced on an annual term and pulled live from the very catalogue that feeds the pricing page, so it cannot drift out of date. Other columns show the ranges shared hosting tends to advertise inside each bracket: introductory rates that normally ask for a one-to-four-year commitment, then climb once that term expires. Naming individual competitors and printing their prices is something we have stopped doing. A figure we cannot re-check on the day you read it has no business sitting in front of you. So compare us with whoever you are genuinely weighing up, and read the renewal line first. That line tells you more than the headline ever will.
First Steps
From choosing to live
- 1
Point every job's output at a shared inbox
Not the client's mailbox and not an individual's. An alert going to somebody who left in March is functionally identical to no alert at all.
- 2
Stagger the fleet across the small hours
Everybody schedules for midnight, which is why everybody's jobs collide. Ten past, twenty past, half past — the mysterious partial failures mostly stop.
- 3
Audit the job list once a year
Half of it relates to a removed plugin or a report nobody reads. Removing those is free performance and one less thing you cannot explain.
In the Box
Packed with every plan
- Real system cron with minute-level scheduling on the account
- Notification address set per job rather than defaulting to the owner
- Execution limits documented before a long job is written
- Output captured somewhere a failure can actually be diagnosed
- wp-cron replacement built into account provisioning
- Jobs staggered across accounts to avoid contention
- A written inventory of every job across the fleet
- Daily backups with restores you run yourself
- cPanel, so the cron screen is where every tutorial says it is
- A ladder of tiers for the client whose job outgrows shared limits
Across the Counter
Things people ask us all the time
Where should cron output go on a managed client account?
To a shared inbox you monitor, set deliberately when the job is created. The default is the account owner, which is usually either somebody who will ignore it or somebody who will be alarmed by it. Use a role address rather than an individual's, so the alert survives a staff change.
How do I tell a stopped job from a working one?
You cannot, if it only speaks when it fails. That is the most common gap on an otherwise well-run fleet: silence is indistinguishable from success. Either have the job report success somewhere, or check its log on a schedule. A failure you can act on is much cheaper than a client noticing stale data three weeks later.
What is the standard way to replace wp-cron across many sites?
Disable WP-Cron in wp-config and add a system cron calling wp-cron.php every few minutes. The trick across a fleet is to make it part of account provisioning rather than something a person remembers, so every new client site is identical and you never have to work out which ones were done.
Why do nightly jobs fail intermittently across a client fleet?
Collisions, usually. Everybody schedules at midnight or two, so disk and CPU contention produces partial failures that look mysterious. Stagger the fleet across the small hours. If one client's job genuinely will not fit inside the execution limits, that is a signal to move them up a tier rather than to fight it nightly.
Read next
White-Label Hosting
Selling hosting under a name of your own, and the structure that sits behind it.
Hosting With Redis Object Caching
Object caching for client shops, and how to diagnose the complaint before spending anything.
Web Hosting
cPanel hosting on NVMe with SSL, migration and the first year of the domain included.
Domain Names
Search, register and transfer names — the first year free with annual hosting.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Schedule it once and be able to prove it ran.
Real system cron on every account, output routed where you choose, and a ladder for the client whose job outgrows it.
See Web Hosting plans