Retries & Failure Handling
When a request fails, QuzenixCron automatically retries before giving up and sending you an email. Settings are per-job, so you can tune it for both critical endpoints and flaky ones.
How Retries Work
For each failed execution, QuzenixCron will attempt up to 1 + max_retries times. So if max_retries = 3, you get 4 total attempts (1 initial + 3 retries).
Between attempts, there's a delay of retry_delay_seconds. Default is 60 seconds. The delay is fixed — the same wait between every attempt, not exponential backoff. Once all attempts are exhausted, the job is marked as failed and a notification email is sent.
Per-Job Settings
| Field | Range | Default | Notes |
|---|---|---|---|
max_retries | 0–10 | 3 | 0 = no retries, fails immediately |
retry_delay_seconds | 10–3600 | 60 | delay between attempts |
timeout_seconds | 1–120 | 30 | per-attempt timeout |
max_retries and retry_delay_seconds per job.Example Scenario
Settings: max_retries: 3 retry_delay_seconds: 60 timeout_seconds: 30 Timeline if the target is down: 00:00 → Attempt 1 (times out after 30s) 01:00 → Attempt 2 (failed) 02:00 → Attempt 3 (failed) 03:00 → Attempt 4 (failed) → Failure email sent → consecutive_failures += 1
What Counts as a Failure
- HTTP status 4xx or 5xx
- Timeout (target didn't respond in time)
- Connection refused / DNS error
- Invalid response (e.g., SSL error)
When the Email Gets Sent
By default, you get an email after 1 final failure (notify_after_failures = 1). Raise it if your endpoint is occasionally flaky and you don't want noisy alerts:
notify_after_failures: 3 → Email sent after 3 consecutive final failures
The consecutive_failurescounter resets to 0 on any successful execution. So a fail-succeed-fail pattern won't build up toward the threshold.
notify_after_failures = 3 and retry_delay = 120. You'll only get paged if things are actually broken for more than a few minutes.Manual Run
The Run nowbutton on the job detail page bypasses the retry loop and doesn't update the notification counter. Great for quick testing without affecting your normal schedule.
Concurrency Lock
QuzenixCron uses an atomic database lock to prevent double-execution. Once a job is claimed, it can't be claimed again until it finishes (lock timeout is 15 minutes). So even though the worker ticks every 30 seconds, each scheduled run executes exactly once.