Scheduling & Retries

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

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.

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

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:

Using IP Allowlists

• For Vercel users: If your application is hosted on Vercel, 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.
• For 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.

Automation & Updates

For automated allowlist management:

• Fetch the JSON file programmatically to keep your firewall rules up-to-date.
• Use the regions 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.