All about crons

Want to schedule a recurring command on a node? This article explains how to create and configure crons in Core, and the behaviour worth knowing once they're running.

Where to find crons

Crons are managed per UNIX user. In Core, open a UNIX user — the 'Crons' section lists its crons and offers a '+' button to create one.

Creating a cron

The 'Create Cron' modal opens with a 'Type' dropdown:

• 'Custom command' — write any command yourself.
• 'Schedule (Laravel)' — pre-fills php …/artisan schedule:run, schedules every minute, and turns off locking (Laravel handles its own with withoutOverlapping).
• 'WP-Cron (WordPress)' — pre-fills wp --path=… cron event run --due-now, schedules every minute, leaves locking on.

The remainder of the modal is the same regardless of type, with an 'Show advanced options' expandable for less-common fields.

Standard fields

• 'Name' — lowercase, digits, dash, underscore. Identifies the cron.
• 'Command' — what to run. The command itself may not call exit — let your script's normal exit code propagate.
• 'Email Address' — where failure notifications go. Leave empty to send to Cyberfusion.
• 'Schedule' — preset (every 5 minutes / minute / hour / 4 hours / day) or 'Custom' for a free-form cron expression.
• 'Locking Enabled' — prevents two instances of the same cron from running at once. On by default. Turn off only if the command handles its own locking.
• 'Active' — toggles whether the schedule actually fires.
• 'Node' — which node runs the cron.

Advanced options

• 'Error Count' — send an email after this many consecutive failures. Counter resets after any successful run. Default '1' (email after every failure).
• 'Random Delay (s)' — randomise each run's start by up to this many seconds. Use to stagger crons that share a schedule, so they don't all hit the node at the same instant. Default '10'.
• 'Timeout (s)' — kill the cron after this many seconds. A failsafe for commands that may unexpectedly hang (e.g. blocked external API calls). Without a timeout, a hung run can sit forever — and (if locking is on) block every subsequent scheduled run.
• 'Memory Limit (MiB)' — kill the cron if it exceeds this. Minimum 256.
• 'CPU Limit (cores)' — throttle the cron to at most this many CPU cores.

Behaviour worth knowing

What counts as a failure

A cron run has failed when the command exits with a return code other than 0. Failure emails contain that return code along with the command's output.

Stop-spamming guard

If a cron fails more than 10 times consecutively, Cyberfusion stops sending failure emails until the cron succeeds again. This prevents an indefinitely broken cron from flooding your inbox.

Don't redirect to /dev/null

Don't append > /dev/null to the command. Notifications fire only on a non-zero exit, not on output — so there's nothing to suppress. The 'Create Cron' modal flags this with a warning if it detects the redirection.

Locking and Laravel

Locking is on by default. The one common exception is Laravel: its scheduler handles concurrency itself (withoutOverlapping), which is why the 'Schedule (Laravel)' type preset turns Cyberfusion's locking off automatically.

PHP and Node.js versions

The cron runs as the UNIX user — which means it inherits that user's default PHP and Node.js versions. A bare php or node in your command always resolves to the version set on the UNIX user, the same way an interactive shell session would. See UNIX user namespacing for how that works.

Use cases by target group