Timezone for cron evaluation. Only 'UTC' is supported in this release.

Distributed lock configuration.

When absent or enabled: false a MemoryLock is used (process-local). When storage: 'redis' a RedisLock is used for multi-instance safety.

Jobs registered declaratively, as an alternative to calling scheduler.cron()/every()/delay() imperatively after start(). Each entry — instance or RegistryFactory — produces one registration call, dispatched on its trigger, so a job can be declared where the plugin is composed instead of after the application has started.

Instance entries register during the plugin's register() phase, identical to the imperative timing. Factory entries are resolved in the onInit phase — the first at which the registry holds every capability — so a factory can build its definition from a resolved capability. A factory that throws rejects start() with an error naming SchedulerPlugin({ jobs }) and the entry's index in THIS declared array, not its position among the factories.

On Cloudflare Workers the plugin refuses registration outright (SchedulerUnavailableError) before any entry is read — the refusal fires before an instance registers and before onInit can resolve a factory.

Ingress behaviours wrapped around every job handler — the scheduler arm of the transport-neutral behaviour chain shared with the websocket, queue, and messaging plugins (IIngressBehavior in @setu-ts/common).

Each behaviour observes an IngressContext carrying kind: 'scheduler', the job name as name, the delivered ScheduledJob as payload, and the 1-based attempt, and runs in declared order ahead of the handler — INSIDE the distributed lock, so a replica that loses the lock runs no behaviour for that fire. A behaviour that returns without calling next() short-circuits: the handler never sees the fire. A behaviour that throws follows the handler's own failure path — retried per the job's RetryOptions exactly as a handler throw is. Every registration is wrapped — imperative cron()/every()/delay() calls included — so a mixed application cannot leave a handler unchained.

With no behaviours configured, dispatch is byte-identical to the pre-chain behaviour: the handler is handed the job directly, with no chain allocated.

When an entry is a FACTORY, dispatch is HELD until onInit has resolved the whole chain, so nothing reaches a handler through a partial one. That gate covers every registration — this plugin's declared entries and any a later plugin makes imperatively through the resolved capability — which is why no registration's timing has to change. It is released once and costs nothing thereafter.

Instance entries are handed to the service at register(); factory entries are resolved in the onInit phase and a throwing factory rejects start() naming SchedulerPlugin({ behaviors }) and the entry's index in THIS declared array.