Aller au contenu

Scheduled work

Ce contenu n’est pas encore disponible dans votre langue.

Not all work stays up. A migration runs once and finishes; an import runs monthly and finishes. Describing those as long-running deployments means the platform restarts them when they succeed, which is exactly wrong.

Scheduled work adds its own questions, and every one of them has a wrong answer that looks reasonable: what happens when a firing arrives while the previous run is still going; what happens to a firing the platform missed because it was down; and what time zone the schedule is read in when nobody said.

Work that finishes is a different kind of thing. A job runs to completion, retries within a limit you set, may be bounded by a deadline, and its record is kept for a period you choose. It is not restarted when it succeeds. The fields are in the job reference.

A schedule owns one job and re-runs it. Each firing is the next run of the same named job, rather than a new job per firing. Kubernetes does the opposite, and the difference is deliberate: a fresh name per firing gives every run the same run number and scatters the retention limit across unboundedly many names.

Every ambiguity is answered in the description, not inherited. The time zone is stated rather than taken from whatever the process happened to be running in. What happens to an overlapping firing is a policy you choose. How late a missed firing may still start is a window you set, with an explicit way to say “never catch up”.

Suspending is a first-class tool, not a convenience. A suspended schedule evaluates nothing at all, which makes it safe to apply at any moment — including while a run is in flight — and reversible without touching the schedule, the job or its history.

Not this

This page does not cover the cron grammar, the concurrency policy names, the retention limits or the deliberate rejections. They are generated into the cronjob reference.

It also does not cover long-running work, which is deployments and containers.