Getting Started
Overview Quickstart
Monitors
Overview Monitor Types Intervals & Probes Advanced Options
Status Pages
Overview Setup Customization Custom Domains Uptime History
Incidents
Overview Managing Incidents Maintenance Windows
Agent
Installation Configuration Upgrading Uninstallation Requirements Troubleshooting
Plugins
Overview Redis MySQL PostgreSQL MongoDB Nginx Apache PHP-FPM Memcached RabbitMQ Elasticsearch Meilisearch Varnish HAProxy Docker VictoriaMetrics mdadm (RAID)
API
Overview Authentication Monitors Incidents Status Pages Errors
RUM & Replay
Overview Quickstart Session Replay Custom Events Error Tracking Troubleshooting
OTLP & Tracing
Overview Distributed Traces Structured Logs Custom Metrics Language SDKs Troubleshooting
Observability Apps
Overview Creating Apps Quota Management Domain Whitelist Top-Up Credits
Alert Manager
Overview Anomaly Detection Alert Channels Thresholds
Teams
Overview Roles & Permissions Invitations Seats & Billing
Billing
Overview Plans & Quotas Top-up Credits Invoices & Portal
Security
Overview Two-Factor Auth API Tokens Sessions

Intervals & Probes

This page covers how often a monitor checks, how long it waits, how it retries, and which probe locations run the check. These four settings determine how fast you detect problems, how reliable detection is, and from where you measure.

Check Interval

The check interval (interval_seconds) is how often a probe runs the check. Shorter intervals detect outages faster but use more of your plan's quota.

The available intervals depend on your subscription plan:

Plan Available intervals
Free 15 min, 30 min, 1 h, 2 h, 3 h, 6 h, 12 h, 24 h
Pro 1 min, 2 min, 5 min, 10 min, 15 min, 30 min, 1 h, 2 h
Business 30 s, 1 min, 2 min, 5 min, 10 min, 15 min, 30 min, 1 h
Enterprise 10 s, 30 s, 1 min, 2 min, 5 min, 10 min, 15 min, 30 min, 1 h

The monitor form only offers the intervals allowed by your plan, and the value is validated on save β€” choosing an interval outside your plan is rejected.

Tip. Match the interval to how critical the target is. A customer-facing API on Business/Enterprise can run every 30 seconds; an internal dashboard might only need a 15-minute check.

Timeout

The timeout (timeout_seconds) is how long a probe waits for a response before treating the check as failed. The allowed range is 1 to 60 seconds.

  • Too short β†’ slow-but-healthy targets get marked down (false positives).
  • Too long β†’ genuine outages take longer to detect, and a stuck connection ties up the probe for the full timeout.

A typical web endpoint works well at 10-30 seconds. Set it comfortably above the target's normal response time.

Retries

The retry count (retry_count, default 3) is how many additional attempts a probe makes after a failed check before recording a failure. Retries absorb transient network blips so a single dropped packet doesn't open an incident.

check fails β†’ retry 1 β†’ retry 2 β†’ retry 3 β†’ still failing β†’ record failure

Retries interact with the failure threshold: a monitor is marked down only after the configured number of consecutive failed checks. Higher retry counts reduce false alarms at the cost of slightly slower detection.

Multi-Region Probes

StatusRadar runs checks from distributed probe servers in multiple regions. When you create a monitor you can pick which probes run it; if you select none, the monitor is assigned to all online probes.

Why use multiple regions

  • Eliminate false positives β€” an outage seen from one region but not others is usually a network issue, not a real outage.
  • Measure global performance β€” see response time from the regions where your users are.
  • Detect regional failures β€” catch CDN, routing, or geo-DNS problems that only affect some areas.

Selecting probes

In the monitor form, probes are grouped by region. Pick the locations relevant to your audience:

  • A single-region service β†’ one or two nearby probes.
  • A global service β†’ probes across the regions you serve.
  • Maximum confidence β†’ all available probes (the default when none are selected).

Plan limits. The number of probe locations you can use is governed by your plan's quota. Higher plans unlock more regions.

How probe assignment works

When a monitor is created, it is linked to each selected probe (stored in monitor_locations). Each probe independently pulls the monitors assigned to it, runs the checks on schedule, and POSTs results back. Status and uptime in the dashboard aggregate results across all assigned probes.

How the Schedule Runs

A probe picks up a monitor for checking when:

last_checked_at IS NULL                                  (never checked β€” runs immediately)
OR last_checked_at + interval_seconds <= now             (interval has elapsed)

So a brand-new monitor checks on the next probe cycle and shows Pending only until that first result arrives. After each run, the monitor's last_checked_at is updated and it waits a full interval before the next check.

Next Steps

On this page