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

Monitors Overview

A monitor is a single check that StatusRadar runs on a schedule against a target you care about β€” a website, an API endpoint, a TCP port, a DNS record, an SSL certificate, or a server. Each monitor records uptime, response time, and status over time, and can trigger incidents and alerts when something goes wrong.

What a Monitor Does

Every monitor runs the same loop:

  1. Schedule β€” wait until the configured check interval elapses.
  2. Check β€” a distributed probe contacts the target and measures the result (success/failure, response time, status code, and type-specific data such as SSL expiry or DNS records).
  3. Retry β€” if the check fails, retry up to retry_count times before recording a failure (avoids false alarms from a single network blip).
  4. Record β€” the result is sent to the StatusRadar API and stored in VictoriaMetrics as probe_monitor_status, probe_response_time_ms, and probe_monitor_uptime.
  5. Evaluate β€” failure/recovery thresholds decide whether to open or close an incident and fire alerts.

Monitor Types

StatusRadar supports six monitor types. Each shares a common set of fields and adds its own target format and options.

Type Checks Target example
HTTP / HTTPS Web pages, APIs, endpoints https://example.com/health
SSL TLS certificate validity and expiry example.com
TCP A port is open and accepting connections db.example.com + port 5432
Ping Host reachability (ICMP) example.com
DNS A DNS record resolves to the expected value example.com
Server Host metrics via the installed agent a server registered with the agent

See Monitor Types for the per-type target format and options.

Common Fields

Every monitor (HTTP/HTTPS, SSL, TCP, Ping, DNS) shares these fields:

Field Description
name Display name (3-255 characters).
type One of http, https, ssl, tcp, ping, dns.
target What to check (URL, hostname, etc.). Max 500 characters.
group_name Optional grouping label for the dashboard (defaults to General).
interval_seconds How often to check. Allowed values depend on your plan.
timeout_seconds How long to wait for a response (1-60 seconds).
retry_count Retries before recording a failure (default 3).
probe_servers[] Which probe locations run the check (defaults to all online probes).
is_active Whether the monitor is running or paused.
notify_on_failure Send an alert when the monitor goes down.
notify_on_recovery Send an alert when the monitor comes back up.

Type-specific fields (HTTP method, expected status, SSL expiry window, DNS record type, TCP port, and more) are covered in Advanced Options.

Monitor Lifecycle

Creating a Monitor

Dashboard β†’ Monitors β†’ Add Monitor

  1. Choose a type and enter a target.
  2. Set the check interval and timeout.
  3. (Optional) Pick the probe locations that should run the check.
  4. (Optional) Configure type-specific options.
  5. Save. The new monitor is assigned to the selected probes (or all online probes if none are picked).

For HTTP/HTTPS monitors, the target is validated against SSRF protections β€” private IP ranges, localhost, link-local addresses, and cloud metadata endpoints are rejected.

Plan limits. Creating a monitor counts against your plan's monitor quota. When you reach the limit, you must upgrade before adding more.

Pending β†’ Up / Down

A freshly created monitor shows Pending until its first check completes. After that, its status reflects the most recent probe result:

Status Meaning
Up Last check succeeded.
Down The failure threshold was reached.
Degraded / Timeout Slow or timed-out response (still reachable).
Pending No check has run yet.
Paused The monitor is inactive (is_active = false).

Incidents and Recovery

When consecutive failures cross the failure threshold, StatusRadar opens an incident and (if notify_on_failure is set) sends alerts. When the monitor recovers and crosses the recovery threshold, the incident is resolved and a recovery alert is sent if notify_on_recovery is enabled. See Alerts Overview.

Pausing and Resuming

Pausing a monitor (the toggle on the monitor list or detail page) stops checks without deleting history. Resume it at any time to start checking again.

Editing and Deleting

You can edit a monitor's name, interval, timeout, retries, notification settings, and type-specific options. The type and target are fixed after creation β€” to change them, create a new monitor. Deleting a monitor removes it and its assignments permanently.

Where the Data Goes

Check results are not stored in MySQL. Probes POST results to the StatusRadar API, a Go collector writes them to VictoriaMetrics, and the dashboard queries VictoriaMetrics for uptime, response-time charts, and status. Uptime and average-response-time queries are cached for 60 seconds.

Next Steps

On this page