Retry Schedule
When a delivery fails, Transyt retries with exponential backoff and jitter. This spreads out retries to avoid overwhelming your application during outages.
Backoff Formula
Section titled “Backoff Formula”delay = min(MAX_DELAY, BASE_DELAY * 2^attempts) ± JITTER| Constant | Value |
|---|---|
BASE_DELAY | 10 seconds |
MAX_DELAY | 4 hours (14,400 seconds) |
JITTER | ±20% of the computed delay |
MAX_ATTEMPTS | 10 |
Retry Timeline
Section titled “Retry Timeline”| Attempt | Approximate Delay | Cumulative Time |
|---|---|---|
| 1 | ~10 seconds | ~10s |
| 2 | ~20 seconds | ~30s |
| 3 | ~40 seconds | ~1m 10s |
| 4 | ~80 seconds | ~2m 30s |
| 5 | ~2.5 minutes | ~5m |
| 6 | ~5 minutes | ~10m |
| 7 | ~10 minutes | ~20m |
| 8 | ~20 minutes | ~40m |
| 9 | ~40 minutes | ~1h 20m |
| 10 | ~1 hour 20 minutes | ~2h 40m |
What Counts as Failure
Section titled “What Counts as Failure”A delivery attempt is considered failed when:
- Your application returns a non-2xx HTTP status code
- The connection times out (30-second timeout)
- The connection is refused or unreachable
- A network error occurs (DNS failure, TLS error, etc.)
Delivery History
Section titled “Delivery History”Each attempt is logged in the event’s delivery_history array with:
- Timestamp
- HTTP response code (if any)
- Response body snippet (first 500 characters)
- Error message (first 500 characters)
You can view delivery history via the Events API or the dashboard.
After All Retries
Section titled “After All Retries”When all 10 attempts are exhausted, the event’s delivery_status is set to failed. See Failure Handling for what happens next.