Vigil

Last reviewed Sep 13, 2026 · 786 words

Vigil runs a full status page, a prober for HTTP, TCP and ICMP targets, and an alert pipeline in about 32 MB of RAM with no database at all. State lives in memory, the config lives in one TOML file, and there is no admin UI, no setup wizard, no accounts. That combination is exactly what you want for a status page that has to stay up when everything else is on fire, and exactly what you do not want if you like clicking "add monitor" in a browser. Decide which person you are before installing, because the file is the whole product.

No database, so it survives the outage it reports

Most status pages keep a database, which means they share a failure domain with the rest of your stack. Vigil keeps everything in RAM and rebuilds from config on restart, so a 32 MB container on a cheap VPS at a different provider from your main servers costs almost nothing and has nothing to break. The trade-off is honest: history does not persist across restarts and there are no long-term uptime percentages on the page. Vigil shows the state of things now, plus announcements you post. If you need "99.97 percent over 90 days" on a public page, that is a different tool.

The config, annotated

[server]
log_level = "warn"
inet = "0.0.0.0:8080"
workers = 4
manager_token = "long-random-string"
reporter_token = "another-long-random-string"

[branding]
page_title = "Example status"
company_name = "Example"
icon_url = "https://example.com/icon.png"

[metrics]
poll_interval = 60
poll_retry = 2
poll_http_status_healthy_above = 200
poll_http_status_healthy_below = 400
poll_delay_dead = 10
poll_delay_sick = 1

[notify]
reminder_interval = 300

  [notify.slack]
  hook_url = "https://hooks.slack.com/services/xxx"

[[probe.service]]
id = "web"
label = "Web"

  [[probe.service.node]]
  id = "site"
  label = "Main site"
  mode = "poll"
  replicas = ["https://example.com/healthz"]

Mount that as /etc/vigil.cfg in the valeriansaliou/vigil image, expose port 8080, put a TLS proxy in front, done. Services group nodes; nodes hold replicas; each replica is a URL for HTTP, tcp://host:port for TCP, or icmp://host for ping. poll_delay_sick and poll_delay_dead are latency thresholds in seconds that turn a node yellow and then red, and they are the settings people forget to tune for slow links. There is no hot reload; a change means a restart, so keep the file in git and treat an edit as a deploy.

Push mode is the part nobody expects

Set mode = "push" on a node and Vigil stops probing it and waits for reports instead. Small reporter libraries exist for Node, Rust, Go and PHP, with community ports elsewhere, that send a heartbeat with CPU and RAM load every 30 seconds authenticated by reporter_token; if the heartbeats stop, the node goes dead. This turns the status page into a health aggregator for services behind NAT, batch workers, and anything that cannot be reached from outside. There is also mode = "script" for a shell check run by Vigil itself and mode = "local" for probes executed by a separate Vigil Local agent inside a private network that reports back. Between them you can cover almost any topology without opening inbound ports.

Alerts and the Manager API

Notifiers include email, Slack, Telegram, Pushover, Gotify, Matrix, XMPP, Twilio SMS, Zulip, Webex and a generic webhook, several at once if you like, with a reminder interval so an ongoing outage nags rather than firing once. Gotify is the low-effort path for a homelab, and ntfy works through the webhook notifier. The Manager API on the same port lets you post and clear announcements with manager_token, so a 3-line script can put "Maintenance until 02:00" on the page from a cron job.

Against Gatus and Uptime Kuma

Gatus is the closest relative: also config-file driven, also tiny. Gatus has richer conditions (JSON path, certificate expiry, DNS), optional persistence for history, and a bigger community. Vigil has push reporting and a cleaner public page. Uptime Kuma is the click-through option with far more users and check types, and it is the safer pick if you are unsure; the status pages overview walks through the choice.

What I'd do

Run Vigil when the status page must be independent of the stack it describes, when you want push heartbeats from internal services, or when you simply prefer config in git. Put it on a VPS costing about 5 dollars a month at a different provider, poll every 60 seconds, wire Slack or Gotify, and commit the config next to your Compose files. If you want history graphs and a mouse-driven UI, it is not the tool, and there is no shame in Uptime Kuma.