Compare
Vigil and Uptime Kuma.
Uptime Kuma is a popular self-hosted monitor, and for a lot of installs it is the right one. This page is the differences that are in the code, including the ones that favor Kuma.
The Kuma counts below are from Kuma 2.4.0, which is the release
Vigil's importer is pinned to, unless a sentence names the current
stable release (2.5.0, read
from the releases page on the date in
scripts/data/uptime-kuma.json). The
seven-tool table is the wider comparison.
For teams and agencies
is the page about roles and client status pages.
Kuma has an incident history
Status pages in the current stable release keep an incident history. That landed in pull request #6469, merged on 20 January 2026, which closed the request for an incident timeline (#862). The pull request is explicit that incident management is per status page, not a global list, and that the history reuses the existing incident records: you create, edit, resolve and delete them on the status page.
Issue #7873, opened 18 September 2026, asks for the same management from the admin area. That is a different request from "there is no incident history". There is one.
Vigil's check loop opens and resolves incidents from monitor
results. The status controller
(src/modules/monitors/status-controller.ts) opens an
incident when the monitor is down, and resolves it when a later
check is up or degraded. Down means the check has been failing for
the failure window. The column default is 120 seconds. A single
failed sample inside the window does not open one.
Each incident has an append-only timeline, internal notes, a postmortem field (plain text, kept as written) and an evidence record. That is Core, along with 40 of Core's check types, status pages with subscribers, four roles (owner, admin, responder, viewer) and the audit page. One organization per install.
Where they differ
| Uptime Kuma | Vigil Core | Vigil Commercial | |
|---|---|---|---|
| Licence and price | MIT. Free. | Apache-2.0. Free. | $149 once per company, not per seat. Source-available. |
| What you run | The Kuma server. SQLite, or MariaDB. Not Postgres. | Two processes and Postgres. | The same stack. |
| Notifications | 94 notification providers, counted from the Kuma 2.4.0 notification list. | 25 native provider types, plus Apprise pointed at a server you run. The Apprise bridge is not a twenty-sixth native integration. | The same channels. Escalation can also send SMS and voice through a Twilio account you supply. |
| Maintenance windows | Yes, in Kuma itself. | No. | Yes. A Kuma import does not copy windows. Until you create them again, imported monitors alert during a window Kuma would have suppressed. |
| Incidents | Incident history on the status page, from pull request #6469. Written there. | Opened and resolved by the check loop. Timeline, notes, postmortem, evidence. | The same incidents, plus recovery and escalation attached to them. |
| Who can log in | One account. No role column. The tracking issue is #128, open since 2021. | Unlimited members. Four roles. Audit log. | The same roles, and more than one organization. |
| Fastest ordinary check | One second, in Kuma's own minimum. | Two seconds on the ordinary scheduler. HTTP, JSON-query and TCP can use a separate plane down to 500 milliseconds. Sizing and limits. | The same. |
| Restart on failure | Not a built-in action. People ask for a script or a container restart in #618 and #2363. A webhook can call a receiver you write. |
A rising restart count is down. The default is 3 restarts in
10 minutes, after a first sample that only records the
count, and the failure window still has to elapse. A signed
webhook on monitor.down can restart. Core does
not re-check that the restart worked.
|
A signed call to your restart hook, a second probe, attempt limits and a cooldown. Hold alerts is what waits to page until recovery fails, and it is off by default. How that works. |
| On-call ladder | A per-monitor resend timer. Not a ladder that stops when someone acknowledges. The request. | Notify the channels you configured. No ladder. | Schedules and a ladder that stops on acknowledgement. |
Postgres for Kuma was requested in #959 and closed unmerged. That is why the database row says SQLite or MariaDB.
Importing, briefly
Core reads a Kuma 2.4.0 database file. All 31 monitor types in its selector have a Vigil check, 29 excluding the Group and Manual entries, which do not probe. A type mapping is not a promise that every row imports. Bare IP addresses, methods other than GET and HEAD, some Docker socket rows, Kafka mechanisms other than SASL/PLAIN, and game ids Vigil cannot place are refused and named on the report.
Notification credentials, tags, maintenance windows, proxies and old heartbeats do not come across. The Kuma import page is the step-by-step, and the migration docs cover the other sources. Fourteen of those are read over the vendor's API and are Commercial. The Kuma file import is Core.
When Kuma is the better choice
Keep Kuma if you are one person and it already covers the monitors. Keep it if you want the MIT licence and a SQLite file, if you want 94 notification providers inside the product, if you want maintenance windows without a paid edition, or if a one second interval on every monitor matters more than a failure window and an incident record.
Vigil is the wrong purchase if what you wanted was a general alert router, or a larger notification catalogue. It is a reasonable one if you want the check loop to open and resolve incidents, with roles, an audit log and a postmortem on the incident, and if you are willing to run Postgres.
Commercial is a further choice, not a requirement. Recovery, escalation, maintenance windows, more than one organization, remote probes and runbooks are on that side. Pricing lists them. Open source says what Core keeps.