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.
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
For additional setup information, see CLI overview.
import { ApiCheck, RetryStrategyBuilder } from "checkly/constructs"new ApiCheck("retrying-check", { name: "Check With Linear Retries", retryStrategy: RetryStrategyBuilder.linearStrategy({ baseBackoffSeconds: 30, maxRetries: 4, sameRegion: false, }), request: { method: "GET", url: "https://api.example.com/health", },})
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:
Stable API
Database Check
// Stable API with predictable retry patternnew ApiCheck("stable-api", { name: "Stable API Endpoint", retryStrategy: RetryStrategyBuilder.fixedStrategy({ baseBackoffSeconds: 30, // Wait 30s between retries maxRetries: 2, sameRegion: true, }), /* More options... */})// Retry pattern: 30s, 30s (total: ~60s)
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:
Gradual Backoff
Service Recovery
// API with gradual backoff strategynew ApiCheck("gradual-backoff", { name: "API with Gradual Backoff", retryStrategy: RetryStrategyBuilder.linearStrategy({ baseBackoffSeconds: 15, // First retry after 15s maxRetries: 3, sameRegion: false, // Try different regions }), /* More options... */})// Retry pattern: 15s, 30s, 45s (total: ~90s)
// Service that might need time to recovernew ApiCheck("recovering-service", { name: "Recovering Service Check", retryStrategy: RetryStrategyBuilder.linearStrategy({ baseBackoffSeconds: 30, maxRetries: 4, maxDurationSeconds: 300, // Cap at 5 minutes }), /* More options... */})// Retry pattern: 30s, 60s, 90s, 120s (total: ~300s)
Use cases: Services that need time to recover, moderate backoff requirements, regional issue detection.
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:
Overloaded Service
Rate-Limited API
// Service that might be overloadednew ApiCheck("overloaded-api", { name: "Potentially Overloaded API", retryStrategy: RetryStrategyBuilder.exponentialStrategy({ baseBackoffSeconds: 5, // First retry after 5s maxRetries: 3, maxDurationSeconds: 300, // Stop after 5 minutes total sameRegion: true, }), /* More options... */})// Retry pattern: 5s, 25s, 125s
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:
// Quick retries for fast servicesRetryStrategyBuilder.fixedStrategy({ baseBackoffSeconds: 30, // Fixed: 30s, 30s, 30s})// Slower retries for heavy operationsRetryStrategyBuilder.linearStrategy({ baseBackoffSeconds: 10, // Linear: 10s, 20s, 30s})// Very quick retries for lightweight checksRetryStrategyBuilder.exponentialStrategy({ baseBackoffSeconds: 5, // Exponential: 5s, 25s, 125s})
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:
RetryStrategyBuilder.exponentialStrategy({ maxDurationSeconds: 300, // Stop retrying after 5 minutes total})
Whether retry attempts should run from the same region as the original failed check, or from different regions to help identify regional issues.Usage:
RetryStrategyBuilder.linearStrategy({ sameRegion: false, // Try different regions for retries})
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.