Define Synthetic Check Schedules & Retries

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

Schedule Check Execution

• 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.
  • Brussels (BE), Melbourne (AU), Oregon (US), London (UK), Frankfurt (DE), North Virginia (US)

Choose an Execution Strategy

• 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.

Configure Retries

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).

Pick a Strategy for Your Use Case

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.

Allowlist IP Addresses

If your infrastructure uses firewalls, Web Application Firewalls (WAFs), or IP-based access controls, you may need to allowlist Dash0's synthetic monitoring IP addresses to ensure checks can reach your endpoints.

Download the IP Address List

Dash0 maintains a public JSON file with all synthetic monitoring IP addresses broken down by region; available here.

Regional IP Addresses

Each monitoring location uses 5 dedicated NAT gateway IP addresses:

Apply Allowlists to Your Platform

• Vercel users: You can configure IP allowlisting using Vercel's Firewall. However, you can skip this step as Vercel automatically recognizes Dash0's synthetic monitoring through their bots registry.
• Other platforms: Add the IP ranges from the JSON file to your firewall, WAF, or security group rules. You can allowlist all regions or only the specific locations you've selected in your check's scheduling configuration.

Automate Allowlist Updates

For automated allowlist management:

• Fetch the JSON file programmatically to keep your firewall rules up-to-date.
• Use the regionsCopy object in the JSON to allowlist only your selected locations.
• IP addresses are generally stable. In case of future changes, they will be updated in the JSON and this documentation.