You can create cron jobs (or scheduled jobs) on Render using any of your GitHub or GitLab repositories.
Just like with web services, you can choose the appropriate runtime environment and branch in the repo that contains your cron job code.
When you push changes to your repo, Render automatically builds a new version of your code for the next scheduled run of your cron job. Each execution of your job runs in a new instance of your code.
Using a cron expression allows you to specify the schedule for the command or script you’d like to run periodically.
Render cron job instances are Linux environments, so the cron command should be one of the following:
- Any valid Linux command like
- An executable bash script containing the command(s) you’d like to run periodically.
Just like any other service on Render, cron jobs can use environment variables for things like database URLs and API keys. You can also use Environment Groups if you need your cron jobs to share environment variables with other cron jobs or services.
Sometimes you need to run a cron job off-schedule, perhaps for debugging. You can always trigger a cron job run manually. As mentioned below, this will cancel a currently running job.
Not all cron jobs tolerate multiple, concurrent runs. This is why Render guarantees that at most one run is active at any given time for every cron job. This raises a few questions.
To keep our single-run guarantee, when you manually trigger a run during another active run for the same cron job, we cancel the active run and start a new one.
To keep our single-run guarantee, the next scheduled run is delayed until the previous run is finished. The delayed job run starts once the previous job is done.
A cron job run will be stopped if it does not complete within 12 hours of starting. For jobs that that need to run continuously, use background workers.
Cron jobs can use up to 1 GB of memory.