retries and retry_interval (milliseconds) on a task. A delivery fails on any non-2xx response or transport error; Schedy waits and tries again until the count is exhausted, then marks the task failed.
Each try is recorded as an attempt in the task’s log, with its status code, error, and duration.
Retry mode
retry_mode selects how the delay between retries is computed. It defaults to fixed.
fixedwaitsretry_intervalbetween every attempt.exponentialwaitsmin(retry_interval * 2^n, cap)with full jitter: each wait is a random point in[0, that ceiling], so a struggling endpoint gets backed off instead of hammered at a constant rate, and retries from many clients spread out instead of synchronising. The cap is fixed at 5 minutes.
Retry-After
When a delivery fails with429 Too Many Requests or 503 Service Unavailable and the response carries a Retry-After header, Schedy honors it.
The requested wait becomes a floor under the next retry’s delay: the retry never fires sooner than the server asked, but a strategy that would wait longer anyway still does.
Both header forms are accepted (Retry-After: 120 and an HTTP-date), and the wait is capped at the 5 minute backoff ceiling so a misbehaving endpoint cannot park a delivery slot indefinitely.
Other statuses ignore the header.
Failure callback
SetSCHEDY_ON_FAILURE_URL and a task that exhausts its retries POSTs a single, best-effort notification there before going quiet, so a permanent failure at 3am is not silent:
on_failure_url (an absolute http(s) URL):
on_failure_url; SCHEDY_ON_FAILURE_URL remains the fallback for tasks that don’t set one.