Retries & Billing
Fliq retries failed jobs automatically. Each attempt — original or retry — counts as one execution toward your billing usage.
How retries work
When a job execution fails (non-2xx response, timeout, or connection error), Fliq schedules a retry with exponential backoff. The retry delay roughly doubles after each attempt.
Attempt 1 — fires at scheduled_at Attempt 2 — ~30s after attempt 1 fails Attempt 3 — ~60s after attempt 2 fails Attempt 4 — ~120s after attempt 3 fails ...
What triggers a retry
- Your endpoint returns a non-2xx HTTP status (4xx and 5xx)
- The connection times out (30s limit per attempt)
- A network-level error prevents delivery
Configuring max retries
Set max_retries on a job or schedule. If not set, the default is 0 (no retries — fail on first unsuccessful attempt).
Free plan: 0 – 3 retries per job Growth plan: 0 – 10 retries per job Enterprise: custom limit
Billing
Every execution attempt is one billable execution — including retries. If a job fires and retries 3 times before succeeding, that's 4 executions billed.
Example
Job: max_retries = 3 Attempt 1 → 503 Service Unavailable → 1 execution billed Attempt 2 → 503 Service Unavailable → 1 execution billed Attempt 3 → 200 OK → 1 execution billed Total: 3 executions
Pricing
- Beta (free): 100,000 credits per day. Resets at midnight UTC. When the limit is hit, new job creation is rejected and pending jobs fail until reset.
- Growth: Coming soon. $1 per 100,000 executions with no daily cap.
- Enterprise: Coming soon. Custom pricing.
Designing for retries
Since your endpoint may be called multiple times, make it idempotent where possible — i.e. calling it twice with the same input should produce the same result without side effects. A good pattern is to include the Fliq job ID in your request body or headers and deduplicate on your side.