StatusRadar Overview

StatusRadar is a professional uptime monitoring platform that combines external checks, server-level metrics, public status pages, and full-stack observability in one product. You watch your endpoints from distributed probes, collect deep metrics from inside your servers with a lightweight agent, publish a branded status page for your users, and route alerts to the channels your team already uses.

This page explains what StatusRadar does and the core concepts you'll work with. If you'd rather start building, jump to the Quickstart.

What StatusRadar gives you

• Uptime monitoring — Check HTTP/HTTPS endpoints, SSL certificates, TCP ports, ping, DNS records, and servers from distributed probes, with configurable intervals, timeouts, and retries.
• Server monitoring (agent) — A small Python agent runs on your Linux servers and reports CPU, memory, disk, network, and per-service metrics through 16 optional plugins (databases, web servers, caches, queues, and more).
• Status pages — Public or private pages that show the live state and historical uptime of the monitors you choose, with your own colors and layout.
• Incidents & maintenance — Track outages from detection to resolution, post updates, and schedule maintenance windows that surface on your status page.
• Alerting — Get notified the moment something breaks, with threshold-based and ML-driven anomaly alerts delivered to email, Slack, Telegram, Discord, webhooks, and more.
• Observability (OTLP + RUM) — Ingest backend traces, logs, and metrics over OTLP, and capture frontend Real User Monitoring (Core Web Vitals, errors, session replay) from the browser.

Core concepts

Monitors

A monitor is a single thing you want to keep an eye on — a URL, a port, a certificate, a DNS record, or a server. Every monitor has a name, a target, and timing fields (interval_seconds, timeout_seconds, retry_count) plus per-type options. The supported types are:

Monitors run from one or more probe servers so you can confirm an outage is global, not local to one region.

The server agent

The agent is a daemon you install on a Linux server to collect metrics from inside the machine — system resources plus optional service plugins (Redis, MySQL, PostgreSQL, MongoDB, Nginx, Apache, PHP-FPM, Memcached, RabbitMQ, Elasticsearch, Meilisearch, Varnish, HAProxy, Docker, VictoriaMetrics, and mdadm). It pairs with a Server-type monitor and powers the server dashboards.

Status pages

A status page is a public-facing (or private) page at /status/{slug} that displays the monitors you assign to it, their current status, and historical uptime. You control the slug, visibility, theme (primary color and layout), and how much history to show (show_history_days of 30, 60, 90, 180, or 365).

Incidents & maintenance windows

Incidents represent outages or degradations — created manually or automatically by anomaly detection. They carry a severity, an affected entity (a monitor or server), a lifecycle of acknowledge → resolve, and timestamped updates. Maintenance windows let you schedule planned work so it shows on your status page and suppresses noise.

Alerts

Alerts turn monitor and metric conditions into notifications. They support failure/recovery thresholds, SSL expiry warnings, response-time spikes, ML anomaly detection, and quota warnings, delivered through multiple channels with grouping and throttling to cut noise.

Teams

A team is a company sub-account that groups resources and people. Roles are owner (billing, team, transfer, delete), admin (manage members), member (manage resources), and viewer (read-only). Members join via email invitation, and seats are tied to your plan.

Observability apps (OTLP + RUM)

An observability app represents one of your applications and holds its telemetry quotas and tokens. OTLP apps ingest backend traces, logs, and metrics; RUM apps ingest browser telemetry (Core Web Vitals, JavaScript errors, session replay, clicks, network). Each app has its own token and, for RUM, a domain whitelist for CORS.

Billing

Plans define quotas for monitors, status pages, team seats, servers, data retention, probe locations, and observability volume (RUM/OTLP). Billing runs on Stripe with auto-renew, and you can buy top-up credits to cover observability overage without changing plans.

How the pieces fit together

                         ┌──────────────────────┐
   Distributed probes ──▶│                      │──▶ Alerts (email, Slack, …)
   Server agent       ──▶│      StatusRadar     │──▶ Status page (/status/{slug})
   Browser RUM SDK    ──▶│                      │──▶ Dashboards & incidents
   Backend OTLP SDK   ──▶│                      │
                         └──────────────────────┘

Probes check your monitors from the outside, the agent reports from the inside, and the RUM and OTLP SDKs stream application telemetry. StatusRadar correlates all of it into dashboards, incidents, alerts, and your public status page.

Authentication at a glance

StatusRadar uses different auth schemes per surface — don't assume everything is a Bearer token:

See API Authentication for details.

Next Steps

• Quickstart — set up your first monitor, agent, status page, and alert
• Monitors overview — monitor types, fields, and probes
• Agent installation — install the server agent
• Status pages setup — publish a status page
• Alerts overview — alert types, channels, and thresholds
• API overview — the full programmatic surface