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, 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. |
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). |
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. |
spec key uses the H syntax.
Single-runtime image: Example cron jobs
Composable image: Example cron jobs
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:Cron job timing
The minimum time between cron jobs being triggered is 5 minutes. 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 thetimezone property property as described for the image type (single-runtime image or
composable image).
To run cron jobs in a timezone other than UTC, set the timezone property.
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 preview environments and production environments that do not yet have a domain attached to them. Such environments with deployments within 14 days have crons with the statusrunning.
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 upsun 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
- Using the CLI
- 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.