Skip to main content

Recurring jobs

A recurring job runs on a cron schedule and takes no payload. Register one with worker.HandleRecurring.

worker.HandleRecurring(w, "NightlyCleanup",
worker.RecurringConfig{
Cron: "0 3 * * *",
Queue: "maintenance",
Timezone: "UTC",
},
func(ctx context.Context, jc worker.JobContext) error {
return cleanupExpiredSessions(ctx)
})

The worker announces every recurring handler's schedule when it starts. Zeridion Flare evaluates the schedule and enqueues the job at the appropriate times; the worker then claims and runs it like any other job.

The handler signature

func(ctx context.Context, jc worker.JobContext) error

Recurring handlers have no payload parameter — everything else matches a payload handler: ctx cancels on timeout/shutdown/server-cancel, jc carries job metadata and ReportProgress, and the return value reports success or failure.

Configuration

FieldMeaningDefault
CronCron expression — required
QueueQueue this handler serves"default"
TimezoneIANA timezone the cron is evaluated inserver default
MaxAttemptsAttempts announced for this job typeworker DefaultMaxAttempts (3)
TimeoutPer-execution deadlineworker DefaultTimeout (30m)

Always set the timezone for non-UTC schedules

Timezone is the IANA zone name (for example "UTC", "America/New_York", "Europe/Berlin") the cron expression is interpreted in. A schedule like 0 3 * * * means "3 AM" in that zone. Omit it and the schedule falls back to the server default zone — which silently runs a non-UTC schedule at the wrong wall-clock time. Set it explicitly whenever the intended time is not UTC.

Registration rules

  • An empty Cron panics — a recurring job must have a schedule.
  • The same rules as payload handlers apply: no duplicate job types, register before Run.

Idempotency

Recurring jobs follow the same at-least-once delivery contract as payload jobs: a job may run more than once if outcome reporting does not reach the server. Keep the work idempotent.

See also