Skip to main content
Learn more about retry strategies in the Alert Retries overview.
Use retry strategies to configure automatic retries for failed check runs. This helps reduce false positives and ensures that temporary network issues don’t trigger unnecessary alerts.
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
For additional setup information, see CLI overview.

Configuration

Retry Strategy Methods

Use the RetryStrategyBuilder methods to apply different retry strategies to your checks and monitors.
MethodDescriptionUse Case
noRetries()No retries are performedChecks that should fail fast
singleRetry(options)Single retry attempt with configurable delaySimple retry for transient failures
fixedStrategy(options)Fixed time between retries (e.g., 5s, 5s, 5s)Predictable retry intervals
linearStrategy(options)Linearly increasing intervals (e.g., 5s, 10s, 15s)Gradual backoff
exponentialStrategy(options)Exponentially increasing intervals (e.g., 5s, 25s, 125s)Aggressive backoff for overloaded services
noRetries()
method
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.
singleRetry(options)
method
Performs exactly one retry after a failure.Usage:
Use cases: Simple retry for transient failures.
fixedStrategy(options)
method
Retries with fixed intervals between attempts. Each retry waits the same amount of time as specified by baseBackoffSeconds.Time between retries with five seconds baseBackoffSeconds and three retries: 5s, 5s, 5s.Usage:
Use cases: Stable services, predictable retry timing, simple backoff requirements.
linearStrategy(options)
method
Retries with linearly increasing intervals. Each subsequent retry waits longer: baseBackoffSeconds × retry_number.Time between retries with five seconds baseBackoffSeconds and three retries: 5s, 10s, 15s.Usage:
Use cases: Services that need time to recover, moderate backoff requirements, regional issue detection.
exponentialStrategy(options)
method
Retries with exponentially increasing intervals. Each retry waits exponentially longer: baseBackoffSeconds^retry_number.Time between retries with five seconds baseBackoffSeconds and three retries: 5s, 25s, 125s.Usage:
Use cases: Overloaded services, rate-limited APIs, aggressive backoff scenarios, circuit breaker patterns.

Retry Strategy Options

baseBackoffSeconds
number
default:"60"
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:
maxRetries
number
default:"2"
Maximum number of retry attempts after the initial failure. The total number of check attempts will be maxRetries + 1.Usage:
Range: 1-10 retries
maxDurationSeconds
number
default:"600"
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:
sameRegion
boolean
default:"true"
Whether retry attempts should run from the same region as the original failed check, or from different regions to help identify regional issues.Usage:
When sameRegion: false, retries are attempted from different regions to help distinguish between regional networking issues and actual service problems.
Use cases: Regional issue detection, network diversity, consistency testing.
onlyOn
RetryStrategyCondition
default:"undefined"
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

Best Practices