Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Scheduling runbook · Intermediate · 15 minutes

How to set up a cron job — Cron Runs in an Empty Environment — Plan For It

The script runs perfectly over SSH and does nothing on a schedule, and cron is not going to tell you why.

The short answer

Cron does not run your shell. There is no profile, no aliases, a minimal PATH and a working directory that is not the one you assumed — so a command that works interactively fails on schedule, and fails without producing an error anywhere you are looking.

The fix is three habits: absolute paths to both the interpreter and the script, output captured to a file while you prove the job works, and a lock for any job that could still be running when the next one fires. After that, cron is boring, which is what you want from it.

By the HostingFast team · Reviewed 24 August 2026

Intermediate

Difficulty grade

5

Stages

Free

Support cost

Proven

Verified on

Written for somebody who can reach a shell and edit a crontab through the panel. It covers why cron fails silently before it covers the five-field syntax, because the syntax is rarely the problem.

The WordPress section is at the end because it is the most common cron job on shared hosting and the reason most people arrive here in the first place.

The environment cron does not give you

An interactive shell reads your profile and builds a PATH containing everything you expect. Cron reads almost nothing: a short PATH, no aliases, no shell functions, and a working directory that is your home rather than the script's own folder.

So bare php script.php fails twice over — cron may not find php, and if it does, the script's own relative includes resolve against the wrong directory. Nothing is logged by default, which is why the job appears simply not to have run.

Writing a command that survives that

Spell out both paths in full: the interpreter and the file. Where the script expects to be run from its own directory, cd into it first and chain with && so a failed cd does not run the script from somewhere unexpected.

One more trap that costs people an afternoon: cron treats the percent sign as a line separator, so any command containing one — a date format, a URL-encoded argument — must escape it as a backslash-percent or the command is silently truncated at that character.

Logging while proving, silence once trusted, locking in between

Redirect both streams to a file while you are setting up: standard output and standard error together. An empty log means the command never executed at all, which points at paths or syntax; a log full of errors means it executed and the script is at fault. Those are two entirely different investigations.

Once several runs come back clean, send output to /dev/null or a rotating log, because unmanaged cron mail accumulates in the account mailbox until it becomes its own problem. And if a run can outlast its interval, wrap it in flock against a lock file — otherwise a slow job overlaps itself and the load doubles.

The WordPress case, and why it matters to speed

WordPress schedules its own tasks and, by default, fires them on visitor page requests. On a quiet site they run late; on a busy one somebody's page load pays for whatever was due. Neither is what you want.

Set DISABLE_WP_CRON to true in wp-config.php and add a real cron calling wp-cron.php every five minutes — or, on the SSH-enabled plans, wp cron event run --due-now over WP-CLI, which is faster because it skips the HTTP request entirely. Scheduled work leaves the request path, and page loads stop carrying it.

Driving a hosting account through the cPanel dashboard

The platform these jobs were scheduled on

Every command and behaviour here was exercised on the stack we operate: the panel's cron interface, the same PATH, the same PHP binaries. Nothing is inferred from another host.

Already hosted somewhere slower? We migrate the whole site free, usually within 24 hours, and it keeps serving visitors throughout.

  • Absolute paths, both of them
  • Logged while it is being proved
  • Locked where runs could overlap
  • Engineers on shift at any hour

Why HostingFast

Standard on every plan

The empty environment explained

No profile, minimal PATH, a different working directory — the reason it ran in SSH and not on schedule.

Absolute paths, both of them

The interpreter and the script, spelled out, because cron resolves neither of them on your behalf.

Percent signs escaped

Cron treats a percent as a line separator, which is how a perfectly good command gets truncated.

Logging while proving

Output captured for the first runs, so executed-and-failed is distinguishable from never-executed.

Overlap prevented

A lock file stops a slow run colliding with the next fire and quietly doubling the load.

The WordPress case handled

Replacing visitor-triggered scheduling with a real cron, and what that removes from page requests.

Quick Start

From order to online

  1. 1

    Write the command with absolute paths and run it in SSH first

    Full path to the binary, full path to the script. If it fails interactively it will certainly fail on schedule, and you will see the error.

  2. 2

    Escape any percent signs

    Cron reads % as a line separator. Date formats and encoded arguments both contain them, and the truncation is silent.

  3. 3

    Add the schedule at the frequency the work needs

    The panel presets cover the usual intervals and the five-field syntax covers the rest. Match the interval to the job, not to your anxiety.

  4. 4

    Capture output for the first runs

    Redirect stdout and stderr into a file. Empty means it never ran; full of errors means it ran and the script failed. Different problems.

  5. 5

    Add locking, then silence it and write down what it is for

    flock where a run could outlast its interval, output to /dev/null or a rotating log once trusted, and a comment saying why the job exists.

Built In

Loaded onto every plan

  • SSH, Git and Composer on the developer-focused plans
  • cPanel — the panel most of the industry already automates against
  • NVMe SSD storage on every tier, not just the expensive ones
  • LiteSpeed caching in the server itself, not bolted on by plugin
  • Daily backups with restores you trigger yourself from the panel
  • Staging environments for testing before anything ships
  • Engineers on shift every hour of every day, not a queue that opens at nine
  • 99.9% uptime as the target, monitored around the clock
  • PHP version set per site from the panel, not per server
  • Renewal billed at the rate you first signed up at

Frequently Asked

What people ask us most often

Why does my cron job produce nothing at all, not even an error?

Because cron sends output to local mail by default, and if nothing is reading that mailbox the error vanishes. Redirect stdout and stderr to a file and run it again. An empty file means the command never executed — a wrong path or a truncated line — while a populated one moves the investigation into the script.

How do I stop two runs of the same job overlapping?

Wrap the command in flock against a lock file, so a second invocation exits immediately while the first is still holding the lock. This matters most for jobs on short intervals that occasionally take longer than the interval — without it, each slow run stacks on the last and the load climbs until something gives.

Do mailboxes ship with the plan, or are they billed separately?

Yes — every hosting plan includes mailboxes on your own domain, with webmail, IMAP, POP and SMTP plus spam filtering switched on from the start. There is also standalone email hosting for a domain whose website lives somewhere else entirely.

Where does the hardware sit, and how much does location cost me?

Our platform runs from a London datacentre with redundant power, cooling and multiple upstream carriers, fronted by server-level caching that keeps cached pages fast for visitors worldwide. For most sites, how the platform is engineered — NVMe disks, LiteSpeed, restrained account density per machine — matters far more to speed than the location does.

Keep reading

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.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Schedule it and stop watching it.

SSH and Git on the developer plans, NVMe on every tier, free migration, and engineers on shift at any hour.

View WordPress Hosting plans