Watch everything you run.

Thirteen kinds of checks, alerts that don’t cry wolf, and status pages your users will actually read, from one small container.

Thirteen ways to check

HTTP(S) with status codes, headers, auth and proxies, plus keyword and JSONPath checks. TCP ports, ping, DNS with nine record types and your own resolver, push heartbeats for cron jobs, Docker containers, WebSockets, domain expiry over RDAP, NTP, Steam game servers, and groups.

TLS certificates and domain registrations warn you before they expire. Tags, groups and maintenance windows keep a hundred monitors as calm as ten.

All monitor types

Monitors Live

WebsiteHTTP(S) keyword · example.com 100%24 h
Public APIJSON query · $.status == "ok" 100%24 h
Nightly backupPush 100%24 h
Edge gatewayPing · 1.1.1.1 100%24 h
Payments webhookHTTP(S) · api.example.com 96.2%24 h

Alerts that don’t cry wolf

A failing check retries on its own interval before anyone hears about it. Alerts fire on settled changes only, recovery messages say how long it was down, and flapping monitors are called out instead of flooding your phone.

Send reminders every few failed checks while it stays down, and escalate to a second channel, say PagerDuty, after a set number of minutes. Upside-down mode flips any check.

How notifications work

Payments webhook Up

Up21:16

Back up after 12 min · sent to Ops Discord and PagerDuty
Escalated21:14

Down for 10 min · sent to PagerDuty
Reminder21:09

Still down after 5 checks
Down21:04

HTTP 503 Service Unavailable · confirmed after 2 retries

Status pages people actually read

Public pages with sections, 90-day uptime bars, response times, incidents written in Markdown (pinned, with history) and scheduled maintenance. Light, dark or automatic, custom CSS, and your own domain.

Every page is also JSON for embedding, and SVG badges put status, uptime, response time or certificate expiry in a README.

Status pages and badges

Website Operational

90 days ago45 days ago 99.98% uptime Today

Confirm outages from somewhere else

Run the same binary in agent mode on another network, in another country. Agents pick up the monitors you mark, run them, and report back to your server.

Turn on outage confirmation and a local failure only becomes down, and only alerts, when the agents agree. A flaky uplink at home no longer pages you at 3 a.m.

Remote agents guide

Website Pending

Local check failed; 2/3 remote agents report up No alert yet. It only goes down when the agents agree.

This serverConnection timed out after 10 s
Frankfurt200 OK · 38 ms
Amsterdam200 OK · 41 ms
New YorkTimed out

Label a container, get a monitor

Mount the Docker socket, or a read-only socket proxy, switch on discovery, and add vigilant.* labels. Vigilant Vole creates the monitor and pauses it when the container goes away.

Monitors you made by hand are never touched.

Docker discovery reference

services:
  payments:
    image: ghcr.io/acme/payments:latest
    labels:
      vigilant.enable: "true"
      vigilant.name: "Payments API"
      vigilant.type: "http"        # default: docker (running + healthy)
      vigilant.target: "http://payments:8080/health"
      vigilant.interval: "30"
      vigilant.group: "Production"
      vigilant.tags: "prod,team:payments"
      vigilant.notify: "Ops Discord"

24 notification providers, plus Apprise for 90 more.

Each channel has a Send test button. Mark one as default and new monitors get it automatically.

Discord
Slack
Microsoft Teams
Google Chat
Mattermost
Rocket.Chat
Matrix
Webex
Feishu/Lark
DingTalk
Telegram
Signal
SMS via Twilio
ntfy
Pushover
Gotify
Pushbullet
Bark
Email (SMTP)
PagerDuty
Opsgenie
Webhook
Home Assistant
Apprise

Built to be operated.

An API for everything, your whole setup in git, and an easy way over from Uptime Kuma.

REST API

Full CRUD for monitors, status pages, incidents, maintenance and settings. A browsable reference in the app, and an OpenAPI 3.1 document.
API docs
Config as code

Export the whole setup as one YAML or JSON file, keep it in git, and apply it back with a dry-run plan first. Merge, replace, or apply on every start.
Config schema
Move from Uptime Kuma

Upload kuma.db (1.23 or 2.x) or a JSON backup. Monitors, groups, tags, notifications, status pages and maintenance come across, and push tokens are kept.
Migration guide
Prometheus and Grafana

A /metrics endpoint with Kuma-compatible metric names, so the Grafana dashboards you already have keep working.
Metrics reference
Roles, 2FA and API tokens

Admin, editor and viewer roles, TOTP with recovery codes, and expiring read or write tokens. Argon2 passwords and a strict Content-Security-Policy.
Security notes
Backup and restore

Download a consistent database snapshot while monitoring keeps running, and restore one on the next start. Upgrades take a snapshot first.
Backups

Small enough to forget about.

One static Rust binary serves server-rendered HTML. No Node.js, no external database, no OpenSSL. Everything it keeps lives in one folder.

Docker image ~18MB Compressed, about 61 MB on disk
Binary ~32MB Static, with everything compiled in
Memory at idle A fewMB Kuma typically uses 100 MB or more
To back up 1folder SQLite, session key and backups in /data

Take a closer look.

Calm in light and dark, live over Server-Sent Events, and just as at home on a phone.

Monitor detail for Website: up, uptime tiles from 24 hours to one year, a 24-hour response-time chart, a 90-day uptime bar, recent events and the TLS certificate with 67 days left. — **Monitor detail.** Uptime from a day to a year, response times, 90 days of history, events and the certificate.

The dashboard on a phone: monitor counters, filter chips and the monitor list, with a tab bar at the bottom. — **On your phone.** The whole app works on a small screen and installs as a PWA.

Public status pages

An overall banner, incidents, sections and 90-day uptime bars, on its own URL or your own domain. This one is in the light theme.

Set up a status page

A public status page in the light theme: a yellow Partial outage banner, an incident about delayed payment confirmations, and Website and API sections with 90-day uptime bars.

Vigilant Vole and Uptime Kuma.

Uptime Kuma is an excellent, mature project with a big community, and Vigilant Vole borrows a lot of its ideas. Here’s an honest comparison with Kuma 1.23 and 2.0.

Feature comparison between Vigilant Vole and Uptime Kuma
Feature	Vigilant Vole	Uptime Kuma
Footprint
Runtime	One static Rust binary, server-rendered HTML (Askama + htmx)	Node.js + Vue SPA
Docker image	~18 MB compressed (~61 MB on disk)	Hundreds of MB
Idle memory	A few MB	Typically 100 MB+
Database	SQLite (bundled)	SQLite, or MariaDB/MySQL in 2.0
Monitoring
HTTP(S), keyword, JSON query, TCP, ping, DNS, push, Docker, Steam, groups, WebSocket	Yes	Yes
Domain expiry (RDAP), NTP monitors	Yes	No NTP; domain expiry varies by version
Database monitors (PostgreSQL, MySQL/MariaDB, SQL Server, MongoDB, Redis)	No	Yes
MQTT, Kafka, RabbitMQ, gRPC, RADIUS, SNMP, SMTP, GameDig, Tailscale	No	Yes
Real-browser (headless Chrome) monitor	No	Yes
HTTP auth	Basic auth	Basic, NTLM, mTLS, OAuth2 client credentials
Alerting
Notification providers	24 native + Apprise (90+ services)	90+ native
Reminders (resend while down)	Yes	Yes
Escalation channels after N minutes	Yes	No
Flap detection	Yes	No
Multi-location checks, outage confirmation	Remote agents	No
Status pages
Status pages, custom domains, badges	Yes	Yes
Status page logo upload, analytics, password protection	No	Yes
Incidents	Multiple per page, pinned, history	One active incident per page
Maintenance windows	Manual, once, daily, weekly	Also cron, day-of-month, every N days
Running it
Multiple users with roles	Admin, editor, viewer	Single user
2FA (TOTP)	Yes, with recovery codes	Yes
REST API	Full CRUD + OpenAPI	No (socket.io; API keys for metrics only)
Config as code, GitOps	YAML/JSON, dry-run, merge or replace	No
Docker label auto-discovery	Built in	No (third-party AutoKuma)
Prometheus metrics	Kuma-compatible names + more	Yes
Long-range uptime after retention	Daily rollups	Aggregate tables in 2.0
Import from the other one	Reads `kuma.db`	–
Interface languages	English, Norwegian	About 50 languages
Built-in Cloudflare Tunnel, remote browsers	No	Yes

When Kuma is the better fit If you need database, MQTT or browser monitors, or a language other than English or Norwegian, Uptime Kuma is the better choice today. Already on Kuma? The importer brings your setup across.

Up in a minute.

Pull the image, map a port and a folder, and open http://localhost:3001. A one-time setup wizard creates your admin account.

Finish setup right away Until the first admin exists, anyone who can reach the page can create one. Set VV_SETUP_TOKEN to require a secret in the setup link.

Docker

docker run -d --name vigilant-vole --restart unless-stopped \
  -p 3001:3001 \
  -v "$PWD/data:/data" \
  --cap-add NET_RAW \
  ghcr.io/ferdinand99/vigilant-vole:latest

Docker Compose

services:
  vigilant-vole:
    image: ghcr.io/ferdinand99/vigilant-vole:latest
    container_name: vigilant-vole
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/data
    cap_add:
      - NET_RAW # raw ICMP fallback for ping monitors

Save it as docker-compose.yml and run docker compose up -d. The full file has commented extras: the Docker socket, a config file and a remote agent.

Unraid

Search for Vigilant-Vole in Community Applications. The template sets the port, the appdata path and PUID/PGID for you. Manual setup

Documentation.

The guides live next to the code on GitHub.

Know the moment something goes down.

Thirteen ways to check

Alerts that don’t cry wolf

Status pages people actually read

Confirm outages from somewhere else

Label a container, get a monitor

24 notification providers, plus Apprise for 90 more.

REST API

Config as code

Move from Uptime Kuma

Prometheus and Grafana

Roles, 2FA and API tokens

Backup and restore

Public status pages

Up in a minute.

Docker

Docker Compose

Unraid