The Scheduling & Retries section controls how often synthetic checks run, from where, and how failures are retried.

Scheduling

Frequency: Set how often the check should run (e.g. every 1 minute, 5 minutes, etc.).
Locations: Define where the checks are executed. Multiple locations help monitor availability worldwide.
- Currently available: Brussels (BE), Melbourne (AU)
- Coming soon: Oregon (US), Frankfurt (DE)
Execution strategies
- All selected locations Runs the check in parallel from all chosen locations at every interval. Best for global uptime monitoring.
- Round-robin Rotates through the selected locations, running the check from one at a time. Reduces load and cost, while still sampling across regions.

Retries help reduce noise from temporary network issues or short outages.

Retry up to Number of retry attempts after a failure (e.g. 3).
Retry interval How long to wait between retries (e.g. 1s, 5s).
- Fixed – Each retry waits the same interval.
Total attempts Shown automatically (initial run + retries). Example: Retry up to 3 → total of 3 attempts (initial + 2 retries).

Common Strategies

Here are some setups frequently used in practice:

High availability / SLA monitoring
- Frequency: every 1 minute
- Locations: all selected
- Retries: 0–1
- Purpose: Immediate detection of downtime, good for alerting customers or meeting SLA guarantees.
Cost-efficient global coverage
- Frequency: every 5 minutes
- Locations: 3–5 worldwide
- Strategy: round-robin
- Retries: 1–2
- Purpose: Detect global or regional issues while keeping monitoring overhead lower.
Performance benchmarking
- Frequency: every 1–5 minutes
- Locations: key customer regions
- Strategy: all selected
- Retries: 0
- Purpose: Gather consistent latency and performance data without retries skewing results.
API stability checks (non-critical)
- Frequency: every 10–15 minutes
- Locations: 1–2 regions
- Strategy: round-robin
- Retries: 2–3
- Purpose: Track general health of staging/test APIs without generating too much traffic.