Scheduled cron for your sites

Every Drupal site needs cron — the periodic housekeeping run that checks for updates, indexes new content for search, cleans up logs and expired caches, and runs whatever scheduled jobs your modules have queued. On an ordinary server you'd have to wire that up yourself. Here you don't: Ægir runs cron for each of your sites on a schedule, and the schedule is yours to change, per site, from the control panel.

The schedule, and where to change it

Out of the box, every site gets its cron run once an hour. You can see this on the site's page in the control panel — look for the Cron line, which shows the current interval and when cron last ran.

To change it:

Open the site in the control panel.
Click Edit (the node edit form, same place you manage domain aliases).
Find the Cron interval field and pick a value.
Save.

The choices run from every minute at the tightest, through the hourly default, up to once a week — plus Disabled, which switches scheduled cron off for that site entirely. Nothing else about the site changes when you disable it; you can still run cron by hand whenever you like (see below).

Two things worth knowing about the schedule:

The interval is a "no more often than", not a stopwatch. Behind the scenes a queue sweeps through your sites once a minute and runs cron for the ones that are due, a few at a time. In practice a site's cron lands within a few minutes of falling due — close enough for any real cron job, but don't expect to set your watch by it.
If you don't see the Cron interval field, your account hasn't been given that permission. It's a host-side switch, so ask your host to enable it.

Clones and imported sites arrive with cron off — on purpose. A fresh clone is usually a staging copy, and you rarely want a copy waking up and sending reminder emails or firing scheduled jobs its live original also runs. So a cloned or imported site starts with cron Disabled. When you promote a copy to be your real site, remember to open its Edit form and set the cron interval you want.

How the scheduled run works

Ægir doesn't reach into your site's database to run cron. It does what any visitor-triggered cron does: it requests the site's protected cron address over HTTPS — the URL that includes your site's secret cron key — and Drupal takes it from there. The right address is picked for your Drupal version automatically, so there's nothing to configure.

Because it's an ordinary web request, one detail matters: where the request goes. By default it goes to your site's own domain first. If that request comes back with anything unexpected — a proxy in the way, an error page — the system retries locally: it sends the same request straight to your own server, carrying your domain in the request's Host header so Drupal still knows which site is being asked. That local retry is what keeps scheduled cron working for sites parked behind CloudFlare or a similar proxy service, where the domain's public address isn't your server at all.

When the domain isn't ready: `cron-proxy.info`

The local trick can also be made the only behaviour. If you create this control file in your account (from your shell or over SFTP):

TXT

~/static/control/cron-proxy.info

…then every scheduled cron request for your sites skips the public domain entirely and goes straight to your own server, Host header and all. The file's contents don't matter — its presence is the switch, and it applies to all sites on your account. Delete it to go back to the default behaviour.

Reach for this when a site's domain doesn't resolve publicly yet (a site built ahead of a DNS cutover, an internal-only name) or when you'd simply rather cron never depended on what sits in front of your server. It's the reliable way to guarantee cron runs for a site whose public DNS isn't pointing home.

Running cron on demand

The schedule doesn't stop you from running cron whenever you want:

From the site itself — as an administrator, Drupal's status report page offers a "run cron" link, and the cron settings page has a button. This works on any working domain or alias of the site.
From your shell — one Drush command:
SH
```
drush @example.com cron
```

If your site uses the Elysia Cron module for finer-grained scheduling, that keeps working — Elysia takes over when cron fires, on the schedule or on demand. From the shell you can also drive it directly:

drush @example.com elysia-cron

When cron waits its turn

Scheduled cron shares the background queue with everything else Ægir does for you, and BOA deliberately holds that queue back at certain moments:

while your nightly backups are running (the account-wide maintenance and database backups covered in Backup and restore), and
while the server load is high, so a busy moment isn't made busier.

This is condition-based, not a fixed window: the moment the backup finishes or the load drops, the queue picks up where it left off and any cron runs that fell due in the meantime happen then. You don't need to do anything — but if you ever notice a site's "last run" time stretching a bit longer overnight, this is why, and it's normal.

If cron doesn't seem to run

A short checklist, in the order worth trying:

Check the site's Cron line in the control panel. If it says Disabled, the interval is set to Disabled on the site's Edit form — common on promoted clones (see above). Set an interval and save.
Run it by hand once with drush @example.com cron and watch for errors. A cron run that fails from the shell will fail on the schedule too — fix what the output points at first.
Domain behind a proxy, or DNS not pointing at your server? Create ~/static/control/cron-proxy.info (above) so the scheduled request goes straight to your server, then give it an hour and check the last-run time.
Last run a few hours old overnight? That's the backup window — see the previous section. It catches up on its own.

If none of that moves the last-run time, open a support request and say which site and what you've tried — the queue itself runs on the server side, where your host can see it.

Where to go next

The site Edit form, and the everyday tasks around it, are covered in Creating and managing a site.
Cloning a site (and why clones arrive with cron off) is in Cloning and moving a site.
drush @site cron and friends are in Drush basics.
The nightly backups your cron politely waits for are in Backup and restore.