Prerequisites
Prerequisites
Before configuring retry strategies, ensure you have:
- An initialized Checkly CLI project
- Understanding of your service’s reliability characteristics and expected failure patterns
- Knowledge of appropriate retry intervals for your specific use case
- Awareness of how retries affect alert timing and incident response workflows
Configuration
Retry Strategy Methods
Use theRetryStrategyBuilder methods to apply different retry strategies to your checks and monitors.
Disables all retries for a check. When a check fails, it immediately triggers an alert without attempting any retries.Usage:Use cases: Critical services requiring immediate alerting, security endpoints, fail-fast scenarios.
Performs exactly one retry after a failure.Usage:Use cases: Simple retry for transient failures.
Retries with fixed intervals between attempts. Each retry waits the same amount of time as specified by Use cases: Stable services, predictable retry timing, simple backoff requirements.
baseBackoffSeconds.Time between retries with five seconds baseBackoffSeconds and three retries: 5s, 5s, 5s.Usage:- Stable API
- Database Check
Retries with linearly increasing intervals. Each subsequent retry waits longer: Use cases: Services that need time to recover, moderate backoff requirements, regional issue detection.
baseBackoffSeconds × retry_number.Time between retries with five seconds baseBackoffSeconds and three retries: 5s, 10s, 15s.Usage:- Gradual Backoff
- Service Recovery
Retries with exponentially increasing intervals. Each retry waits exponentially longer: Use cases: Overloaded services, rate-limited APIs, aggressive backoff scenarios, circuit breaker patterns.
baseBackoffSeconds^retry_number.Time between retries with five seconds baseBackoffSeconds and three retries: 5s, 25s, 125s.Usage:- Overloaded Service
- Rate-Limited API
Retry Strategy Options
Time to wait before the first retry attempt. Also used as the base value for calculating subsequent retry intervals in linear and exponential strategies.Usage:
Maximum number of retry attempts after the initial failure. The total number of check attempts will be maxRetries + 1.Usage:Range: 1-10 retries
Maximum total time to spend on all retry attempts. If the calculated retry schedule would exceed this duration, retries stop early. The maximum value is 600 seconds (10 minutes).Usage:
Whether retry attempts should run from the same region as the original failed check, or from different regions to help identify regional issues.Usage:Use cases: Regional issue detection, network diversity, consistency testing.
When
sameRegion: false, retries are attempted from different regions to help distinguish between regional networking issues and actual service problems.Apply the retry strategy only when the failure cause matches the specified condition.Usage:Currently supports
'NETWORK_ERROR' for ApiCheck and UrlMonitor constructs only. Learn more in network retries.Examples
- No Retries
- Fixed Interval Retries
- Linear Backoff
- Exponential Backoff
- Group-Level Retry Strategy
- Project-Level Default
Best Practices
- Stable vs Non-Stable
- Critical vs Non-Critical
- By Check Type