Cron jobs: scheduled tasks that actually run

A cron job is a command the server runs for you on a schedule — every fifteen minutes, every night at 3 AM, every Sunday. Cron jobs are included on every plan, and you manage them yourself from the portal. No ticket, no upsell.

Because every account runs in its own isolated container, your cron jobs run inside your container, under your account, against your plan’s resource guarantees. They can’t be starved by a neighbor’s runaway script — and yours can’t starve anyone else.

Creating a cron job from the portal

1. Log in at my.candorhost.com and open your hosting service.
2. Under Apps & developer tools, open the Cron jobs tab.
3. Fill in the two fields:
   • Schedule — five space-separated fields in standard cron syntax, e.g. 0 3 * * *.
   • Command — the command to run, e.g. /usr/bin/php ~/public_html/cron.php.
4. Click Add. The job appears in the list above the form and starts running on schedule.

To remove a job, click the trash button next to it. Some lines are marked system with a lock icon — those are managed by the platform (the WordPress scheduler is the common one) and can’t be removed from the portal.

Each website has its own crontab; the portal tab edits the one for your service’s primary website. If you’re on a multi-site plan and want to schedule tasks for another site, use Open control panel from your portal — the panel has cron management per site.

Cron syntax, quickly

The schedule is five fields, left to right:

minute  hour  day-of-month  month  day-of-week

• minute: 0–59
• hour: 0–23
• day-of-month: 1–31
• month: 1–12
• day-of-week: 0–6, where 0 is Sunday

* means “every”, */N means “every N”, and A-B means a range. Common schedules:

Schedule	Runs
*/15 * * * *	every 15 minutes
0 * * * *	hourly, on the hour
0 3 * * *	daily at 3:00 AM
0 0 * * 0	weekly, Sunday at midnight
30 2 * * 1-5	weekdays at 2:30 AM
0 6 1 * *	monthly, on the 1st at 6:00 AM

Cron runs on the server’s clock, which may not match your local time zone. If a job needs to fire at a specific local time, check when it actually runs the first day and adjust.

Real examples

Replace wp-cron with a real cron

Out of the box, WordPress runs its scheduler (wp-cron) piggybacked on page visits: someone loads a page, WordPress checks whether anything is due. On a quiet site, scheduled posts publish late and backups don’t fire; on a busy one, the check adds overhead to real visitors. A real cron job fixes both.

First, tell WordPress to stop doing it itself — add this to wp-config.php:

define('DISABLE_WP_CRON', true);

Then add a cron job that runs the scheduler directly:

*/5 * * * *   /usr/bin/php ~/public_html/wp-cron.php

One note before you do: WordPress sites on our platform may already have a system-marked cron line running the WordPress scheduler — you’ll see it locked in the list. If it’s there, the platform is already handling this for you and you don’t need to add your own. (More on how we run WordPress: WordPress on Candor Host.)

Warm your cache

Server-side caching is included on every plan, but a cache only helps once it’s populated. If your traffic is bursty, the first visitor after a quiet stretch pays the price of a cold cache. A warmer keeps your key pages hot:

*/10 * * * *   curl -s https://yourdomain.com/ > /dev/null 2>&1

Hit two or three of your most important pages, not your whole sitemap — the point is to keep the front door warm, not to crawl yourself.

Clean up old files

Anything your site generates — exports, temp files, old logs — counts against your storage and your inode (file count) limit. A nightly sweep keeps it from creeping:

0 4 * * *   find ~/public_html/exports -name "*.zip" -mtime +7 -delete

That deletes ZIP files in exports/ older than seven days, every night at 4 AM. Adjust the path and pattern to whatever your site actually accumulates. Your current storage and limits are on the platform page and live in your portal’s Usage & resources tab.

Gotchas worth knowing

Long-running jobs count against your process limit. Your plan guarantees resources, and it also caps concurrent processes — 20 on Solo, 40 on Studio and Org (the full table is on the platform page). That count includes everything: PHP serving your visitors, your SSH session, and every cron job currently running. A cron job that grinds for twenty minutes is twenty minutes of one process slot gone. Keep scheduled work short, and schedule heavy work for your quiet hours.

Overlapping runs pile up. If a job scheduled every 5 minutes sometimes takes 8, a second copy starts before the first finishes — and now they’re competing with each other and with your site for those process slots. Two defenses: schedule less aggressively than the job’s worst-case runtime, and make the job refuse to start if it’s already running (flock -n is the standard tool for wrapping a command in a lock).

Send output somewhere you can read it. Don’t rely on cron mailing you results — capture them yourself by appending a redirect to the command:

0 3 * * *   /usr/bin/php ~/public_html/cron.php >> ~/cron.log 2>&1

That writes both output and errors to ~/cron.log, which you can read over SSH or FTP. Then remember the cleanup example above — a log that grows forever is its own problem.

Related

• PHP versions and limits — which PHP binary your commands run against
• FTP, SSH, and your files — testing commands by hand before scheduling them
• Backups — already automatic; no cron job needed
• Stuck? Candid Support answers plainly — open a ticket.