Scheduled tasks

If you need to do something every once in a while, such as sending e-mail updates, you can set up scheduled tasks using cron syntax. These "jobs" are triggered by sending HTTP requests to your application.

[cronjobs.update-thing]
    schedule="13 * * * *"
    path="/api/v1/run_scheduled_task"
    method = "POST"

    [cronjobs.update-thing.headers]
        Authorization = "Bearer asdf123"

This will execute a POST HTTP-request to /api/v1/run_scheduled_task 13 minutes after every hour. Timestamps for cron jobs are specified in UTC, so if you want to run a task 8 AM GMT summer time, you'll need to convert that to 6 AM UTC, and then to 0 6 * * * in cron syntax.

Your app must respond to the request within 10 seconds. For long-running jobs, you should return 202 early and then start the job in the background.

The HTTP requests will come from within the cluster. Each environment has its own set of independent jobs.

Retries and guarantees

If your application fails to handle the request, it is retried two times with 10 second intervals. A request is considered to have failed if it times out or if the status code is 400 or higher, but not one of 401, 403 or 429 or 501.

Your app can occasionally receive multiple requests. This might be fine if you're using jobs to remove expired data, but if your job sends a daily e-mail update, it could cause issues. One way to resolve this could be to store the time when the job last started in a database, and checking if the previous job happened too recently.

When deploying a new version of your app, the request can be delivered to both the new and the old pods.

Mission-critical work or jobs that require at-least once or at-most once guarantees should not use scheduled jobs.