Overview
The SDK includes built-in retry logic with exponential backoff. When a network request fails, it automatically retries with increasing delays, improving reliability in unstable network conditions.Default Behavior
By default, the SDK:- Retries up to 2 times on failure
- Uses 500ms base backoff delay
- Doubles the delay after each retry (exponential backoff)
Configuration
Customize retry behavior per trace:Options
| Option | Type | Default | Description |
|---|---|---|---|
maxRetries | number | 2 | Maximum retry attempts |
retryBackoff | number | 500 | Base delay in milliseconds |
Exponential Backoff
The delay doubles after each failed attempt:| Attempt | Delay (default) | Delay (2000ms base) |
|---|---|---|
| 1 | 0ms (immediate) | 0ms |
| 2 | 500ms | 2000ms |
| 3 | 1000ms | 4000ms |
| 4 | 2000ms | 8000ms |
| 5 | 4000ms | 16000ms |
Use Cases
Critical Operations
For important data that must be delivered:Low-Priority Logging
For non-critical data where you want to fail fast:Disable Retries
SetmaxRetries: 0 to disable retry logic:
Error Handling
The SDK handles retries silently - your code doesn’t need to manage failures. However, if all retries are exhausted, the data is lost. For critical operations, consider:- Using more retries
- Implementing application-level backup
- Monitoring for systematic failures
v2 Resilience Improvements
SDK v2 includes several improvements for handling high-volume and unreliable network conditions.Flush Batching
Flush requests are batched — up to 100 items per flush. This reduces the number of network requests and improves throughput.Rate Limiting
The SDK includes built-in rate limiting to prevent overwhelming the gateway during bursts of activity.Keep-Alive Failure Handling
The keep-alive timer automatically stops after 3 consecutive failures, preventing wasted resources on dead connections. See Traces for details.Queue Management
Each trace has a configurable flush queue with a default maximum size of 4096 items. When the queue is full, new items are dropped and theonDropped callback is invoked:
Network Conditions
The retry logic is especially useful for:- Mobile networks - Intermittent connectivity
- Slow connections - Request timeouts
- Server issues - Temporary 5xx errors
- Rate limiting - Brief throttling periods
Best Practices
Match Retries to Importance
Consider Total Time
With exponential backoff, retries can take significant time:| maxRetries | retryBackoff | Max Total Time |
|---|---|---|
| 2 | 500ms | ~1.5 seconds |
| 5 | 500ms | ~15.5 seconds |
| 5 | 1000ms | ~31 seconds |
Don’t Over-Retry
Excessive retries can:- Block the flush queue
- Delay subsequent traces
- Waste bandwidth on permanent failures
Next Steps
TypeScript
Type-safe SDK usage
API Reference
Complete API documentation