Deployment sizing

Vigil has no license-imposed monitor limit. An installation still has finite capacity. Size for the checks you run, their cadence, target latency, worker count and PostgreSQL resources.

Ordinary checks: a batch is not a fleet limit

MONITOR_SCHEDULER_BATCH defaults to 5,000 due monitors per tick, configurable from 1 to 50,000. This bounds a dispatch burst; it is not an installation ceiling or a promise that 5,000 monitors will meet every configured interval.

Checks due at or before the next tick can schedule their own follow-up. The effective interval matters: a consistently healthy monitor can back off and return to the tick path. Increasing the batch alone does not increase worker or database throughput.

Size against your workload

1. Estimate demand from monitor count divided by interval in seconds, separately for each check type and cadence. Allow for adaptive checks and slow targets.
2. Measure the sustained rate and backlog age on your hardware. Add worker replicas if the current workers cannot keep up; give each a distinct VIGIL_ACTOR_NAME.
3. Leave headroom for a worker restart, slow targets and catch-up after outages. Check database resources and queue depth as well as the achieved rate.

The repository suggests dividing required checks per second by the measured rate per worker, rounding up and allowing one additional worker for restart headroom. Treat this as a starting estimate, then verify cadence under representative load.

What the historical batch experiment found

Four workers, local HTTP targets, a 70-second warm-up and approximately 121 seconds observed per run on 12 August 2026. Workers, targets and PostgreSQL shared a machine. These samples describe that workload; they are not a capacity guarantee.

Neither 120-second run met demand. Raising the batch improved this tick-bound workload but did not close the gap. The 60-second runs did not establish a maximum capacity: throughput was bounded by demand. These short runs also did not measure a long-settled healthy fleet whose adaptive interval had backed off.

High-frequency checks: a separate plane

HTTP, JSON-query and TCP checks can use a configured interval down to 500 ms. The high-frequency plane has its own admission and safety bounds:

• 1,000 monitors per worker accepted on this plane.
• 50 high-frequency monitors per organization at admission.
• 2,500 probes per second per worker as a rate-limiter bound, with a burst cap of 128.

These are implementation bounds, not achieved throughput claims. A configured 500 ms interval is not a 500 ms detection or notification time. When the plane cannot keep up, it skips and counts slots rather than promising an interval it cannot deliver.

The historical 1 August 2026 sample at 100 monitors reported a 508 ms p99 interval and zero missed slots. At 1,000 monitors it reported a 1,527 ms p99 interval and 2,157 missed slots. The larger run placed 50 monitors on each target, increasing contention at the per-target limit. Neither sample is a sizing promise for a different deployment.

Measurement context and limitations

These are historical repository measurements, not tests run for this website redesign or a certification of the current release. The high-frequency samples used an AMD Ryzen 7 7445HS, Node 26.4.0 and local PostgreSQL 18.4 with a local HTTP target. Their metadata records a dirty working tree based on 133cea61, so the commit alone does not identify the exact code measured.

The ordinary 60-second batch samples identify clean source 0b4e995c; the 120-second samples identify clean source c25f1ab1. Each downloadable JSON retains its exact commit, environment, observation window and caveats. The source settings above were checked against 7369533d.

PostgreSQL remains a single point of failure unless you provide database failover. Extra workers do not remove that dependency. Inspect backlog age and achieved cadence during normal operation and after a restart.

Read the full scaling notes and reproduction procedure and full high-frequency measurements and caveats. Run benchmarks only in the throwaway environment described there.

Next: production deployment or compare the editions.