Every figure, from the vendor's own page.

Vigil is two processes and one Postgres, a stateless Next.js app you can put behind a load balancer, and a worker that coordinates through the job queue, so you add worker replicas to add capacity. No Redis, no broker, one thing to back up. The full architecture →

Uptime Kuma is a single Node process and its maintainers have said it will stay one: "the current architecture does not use more than one core" (#6040), "we won't become a distributed system", and users report trouble around a thousand monitors (#7239). Clustering has been requested and declined repeatedly (#1259). It also cannot use PostgreSQL as its backing store. SQLite or MariaDB only, and a Postgres port sat open for two years before being closed unmerged (#959).

The current ceiling: the scheduler fans checks out once a minute and enqueues up to 500 per tick, so roughly 500 monitors is the practical limit of this release. Since 1.10.0 the configured interval is a baseline. A monitor that looks suspicious is probed harder, a steady one backs off, and a check due sooner than the next tick schedules its own follow-up. The ordinary floor is two seconds, measured at 2002 ms median for one monitor and 2003 ms for ten (the queue's poll, not contention). HTTP, JSON-query and TCP monitors below two seconds run on a separate plane, which holds 500 ms to 100 monitors on one worker and does not hold it at 1000. Raising the monitor ceiling is on the roadmap.

Unlimited team members in the commercial edition, at no extra cost. Vigil is licensed once per company, never per seat, and since this release, free Core is uncapped too; it had inherited a 100-member limit from a library default. Four roles carry real authority: owner and admin configure, responder handles incidents, viewer reads. Every privileged mutation is written to an audit trail in the same transaction that made the change.

Uptime Kuma has no multi-user support at all. The schema has no role column, setup refuses to create a second account, and the tracking issue has been open since 2021 (#128). The hosted products do support teams, and charge per seat for them: Better Stack bills per responder, StatusCake gives one user on its entry tier. On a five-person team that difference recurs every month.

On the production build, idle, the web server holds ~115 MB RSS and the worker ~180 MB, about 300 MB of application memory before the operating system trims a quiet process further, plus whatever you give PostgreSQL and, if you run browser journeys, their Chromium. Measured over hour-long soak windows with the artifacts committed beside the code in docs/evidence/memsoak, and it fits comfortably on a small VPS, which is the entire point of running it yourself.

There is no head-to-head memory figure here: the other tools were not measured under identical conditions, and an unreproducible number is worthless. One fact needs no benchmark: the four hosted products cannot run on your hardware, so they cannot reach a database, a container or an internal host that is not exposed to the public internet.

Vigil has 42 check types, and 40 of Core's check types are the same set, including push heartbeats, a real browser check, gRPC, Kafka, RabbitMQ, SNMP, Radius, SQL Server, Oracle and game servers. The two the paid edition adds are the scripted-synthetic ones: multi-step API and browser journeys. Uptime Kuma 2.4.0 offers 31 monitor types in its selector, or 29 excluding the Group and Manual entries, which probe nothing. All 31 map to Vigil types: the mapping is generated from the importer's own data, published as kuma-mapping.json, and checked in CI against a database written by Kuma 2.4.0 itself.

Most check types ship in the free edition; the paid edition adds two scripted-synthetic types and charges for what happens after a check fails: a verified recovery attempt, an incident with a lifecycle, an isolated status page per client, a rota that knows whose turn it is. The roadmap says what is being built and carries no dates.