crons
Back to home
On this page
A cron dictionary that defines scheduled tasks for the app.
Optional in single-runtime and composable images.
The keys of the crons definition are the names of the cron jobs.
The names must be unique.
If an application defines both a web instance and worker instances, cron jobs run only on the web instance.
See how to get cron logs.
The following table shows the properties for each job:
| Name | Type | Required | Description |
|---|---|---|---|
spec |
string |
Yes | The cron specification. To prevent competition for resources that might hurt performance, on Grid projects use H in definitions to indicate an unspecified but invariant time. For example, instead of using 0 * * * * to indicate the cron job runs at the start of every hour, you can use H * * * * to indicate it runs every hour, but not necessarily at the start. This prevents multiple cron jobs from trying to start at the same time. The H syntax is available on Grid projects only, and not on Dedicated Gen 2 projects. |
commands |
A cron commands dictionary | Yes | A definition of what commands to run when starting and stopping the cron job. |
shutdown_timeout |
integer |
No | When a cron is canceled, this represents the number of seconds after which a SIGKILL signal is sent to the process to force terminate it. The default is 10 seconds. |
timeout |
integer |
No | The maximum amount of time a cron can run before it’s terminated. Defaults to the maximum allowed value of 86400 seconds (24 hours). |
Note that you can cancel pending or running crons.
Note
The use of the cmd key is now deprecated in favor of the commandskey.
Make sure you set your new cron jobs using the commands key,
and update your existing cron jobs to ensure continuity.
Cron commands 
| Name | Type | Required | Description |
|---|---|---|---|
start |
string |
Yes | The command that’s run. It’s run in Dash. |
stop |
string |
No | The command that’s issued to give the cron command a chance to shutdown gracefully, such as to finish an active item in a list of tasks. Issued when a cron task is interrupted by a user through the CLI or Console. If not specified, a SIGTERM signal is sent to the process. |
applications:
APP_NAME:
type: 'nodejs:24'
source:
root: "/"
crons:
mycommand:
spec: 'H * * * *'
commands:
start: sleep 60 && echo sleep-60-finished && date
stop: killall sleep
shutdown_timeout: 18applications:
APP_NAME:
type: "composable:25.05"
source:
root: "/"
stack:
runtimes: [ 'nodejs:24' ]
crons:
mycommand:
spec: 'H * * * *'
commands:
start: sleep 60 && echo sleep-60-finished && date
stop: killall sleep
shutdown_timeout: 18In this example configuration, the crons spec uses the H syntax.
Note that this syntax is only supported on Grid projects. On Dedicated Gen 2 projects, use the standard cron syntax.
Single-runtime image: Example cron jobs
type: 'php:8.5'
crons:
# Run Drupal's cron tasks every 19 minutes.
drupal:
spec: '*/19 * * * *'
commands:
start: 'cd web ; drush core-cron'
# But also run pending queue tasks every 7 minutes.
# Use an odd number to avoid running at the same time as the `drupal` cron.
drush-queue:
spec: '*/7 * * * *'
commands:
start: 'cd web ; drush queue-run aggregator_feeds'type: 'ruby:3.4'
crons:
# Execute a rake script every 19 minutes.
ruby:
spec: '*/19 * * * *'
commands:
start: 'bundle exec rake some:task'type: 'php:8.5'
crons:
# Run Laravel's scheduler every 5 minutes.
scheduler:
spec: '*/5 * * * *'
commands:
start: 'php artisan schedule:run'type: 'php:8.5'
crons:
# Take a backup of the environment every day at 5:00 AM.
snapshot:
spec: 0 5 * * *
commands:
start: |
# Only run for the production environment, aka main branch
if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then
croncape symfony ...
fi Composable image: Example cron jobs
type: "composable:25.05"
stack:
runtimes: [ "[email protected]" ]
crons:
# Run Drupal's cron tasks every 19 minutes.
drupal:
spec: '*/19 * * * *'
commands:
start: 'cd web ; drush core-cron'
# But also run pending queue tasks every 7 minutes.
# Use an odd number to avoid running at the same time as the `drupal` cron.
drush-queue:
spec: '*/7 * * * *'
commands:
start: 'cd web ; drush queue-run aggregator_feeds'type: "composable:25.05"
stack:
runtimes: [ "[email protected]" ]
crons:
# Execute a rake script every 19 minutes.
ruby:
spec: '*/19 * * * *'
commands:
start: 'bundle exec rake some:task'type: "composable:25.05"
stack:
runtimes: [ "[email protected]" ]
crons:
# Run Laravel's scheduler every 5 minutes.
scheduler:
spec: '*/5 * * * *'
commands:
start: 'php artisan schedule:run'type: "composable:25.05"
stack:
runtimes: [ "[email protected]" ]
crons:
# Take a backup of the environment every day at 5:00 AM.
snapshot:
spec: 0 5 * * *
commands:
start: |
# Only run for the production environment, aka main branch
if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then
croncape symfony ...
fi Conditional crons
If you want to set up customized cron schedules depending on the environment type, define conditional crons. To do so, use a configuration similar to the following:
applications:
myapp:
source:
root: "/"
type: 'php:8.5'
crons:
update:
spec: '0 0 * * *'
commands:
start: |
if [ "$PLATFORM_ENVIRONMENT_TYPE" = production ]; then
platform backup:create --yes --no-wait
platform source-operation:run update --no-wait --yes
fi applications:
myapp:
source:
root: "/"
type: "composable:25.05"
stack:
runtimes: [ "[email protected]" ]
crons:
update:
spec: '0 0 * * *'
commands:
start: |
if [ "$PLATFORM_ENVIRONMENT_TYPE" = production ]; then
platform backup:create --yes --no-wait
platform source-operation:run update --no-wait --yes
fi Cron job timing
Minimum time between cron jobs being triggered:
| Plan | Time |
|---|---|
| Professional | 5 minutes |
| Elite or Enterprise | 1 minute |
For each app container, only one cron job can run at a time. If a new job is triggered while another is running, the new job is paused until the other completes.
To minimize conflicts, a random offset is applied to all triggers. The offset is a random number of seconds up to 20 minutes or the cron frequency, whichever is smaller.
Crons are also paused while activities such as backups are running. The crons are queued to run after the other activity finishes.
To run cron jobs in a timezone other than UTC, set the timezone property as described for the image type (single-runtime image or
composable image).
Paused crons
Preview environments are often used for a limited time and then abandoned. While it’s useful for environments under active development to have scheduled tasks, unused environments don’t need to run cron jobs. To minimize unnecessary resource use, crons on environments with no deployments are paused.
This affects all environments that aren’t live environments. This means all environments on Development plans and all preview environments on higher plans.
Such environments with deployments within 14 days have crons with the status running.
If there haven’t been any deployments within 14 days, the status is paused.
You can see the status in the Console
or using the CLI by running platform environment:info and looking under deployment_state.
Restarting paused crons
If the crons on your preview environment are paused but you’re still using them, you can push changes to the environment or redeploy it.
To restart crons without changing anything:
- In the Console, navigate to your project.
- Open the environment where you’d like the crons to run.
- Click
Redeploynext to the cron status ofPaused.
Run the following command:
platform redeploy