Overview
Cuey automatically retries failed webhook deliveries with configurable retry logic. You can customize the number of retries, backoff delay, and backoff strategy.RetryConfig Structure
The retry configuration consists of three parameters:Parameters
- maxRetries: Maximum number of retry attempts (1-10). Defaults to 3 if not specified.
- backoffMs: Initial backoff delay in milliseconds before the first retry (100-5000). Defaults to 500 if not specified.
- backoffType: Backoff strategy. Options:
exponential(backoff doubles each retry) orlinear(constant backoff). Defaults toexponentialif not specified.
Retry Behavior
When a webhook fails (non-2xx status code or network error):- A new retry event is created
- The retry event inherits the original event’s configuration
- The retry event is scheduled with the configured backoff delay
- The process repeats until
maxRetriesis reached or the webhook succeeds
Backoff Strategies
Exponential Backoff
The delay increases exponentially with each retry:- Retry 1: 1 second delay
- Retry 2: 2 seconds delay
- Retry 3: 4 seconds delay
Linear Backoff
The delay remains constant for each retry:- Retry 1: 2 seconds delay
- Retry 2: 2 seconds delay
- Retry 3: 2 seconds delay
Default Configuration
If you don’t specifyretry_config, Cuey uses these defaults:
Configuration Examples
Quick Retries (Transient Errors)
For transient errors that resolve quickly:Aggressive Retries (Critical Operations)
For critical operations that must succeed:Slow Retries (Rate-Limited APIs)
For APIs that may be rate-limited:No Retries
To disable retries, setmaxRetries to 1:
Retry Event Tracking
Retry events are linked to the original event via theretry_of field. You can:
- Track all retry attempts for a specific original event
- Query events with a specific
retry_ofvalue to see all retry attempts - Understand the relationship between the original event and its retries
Best Practices
Choose Appropriate maxRetries
- ✅ Good:
maxRetries: 3- Most errors resolve in 3 attempts - ❌ Avoid:
maxRetries: 10- May waste resources on permanent failures
Use Exponential Backoff for Most Cases
- ✅ Good: Exponential backoff (default) - Reduces load on failing endpoints
- ✅ Good: Linear for specific cases - When consistent delay is needed (e.g., rate-limited APIs)
Consider API Rate Limits
For rate-limited APIs, use longer delays with linear backoff:Monitor Retry Patterns
Track retry success rates to optimize configuration. Monitor:- Failed events (
status: "failed") - Response status codes
- Error messages
- Retry success rates
Retry Event Lifecycle
- Original Event Fails: Event status changes to
failed - Retry Event Created: New event created with
retry_ofpointing to original - Retry Scheduled: Retry event scheduled with backoff delay
- Retry Executed: Retry event attempts webhook delivery
- Success or Next Retry: If successful, process ends. If failed, create next retry
Configuration Limits
| Parameter | Minimum | Maximum | Default |
|---|---|---|---|
maxRetries | 1 | 10 | 3 |
backoffMs | 100 | 5000 | 500 |