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, schedule, or buffer. If not set, the default is 0 (no retries — fail on the first unsuccessful attempt). The accepted range is 0–20 retries per job, the same on every plan during the beta.

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 executions 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.