Version 1.29.0
Uptime monitoring, recovery and incident operations
Watches.Repairs.Records.
A recovery runtime for the infrastructure you own: it verifies the failure, fires your restart hook, verifies the fix, and writes every step down.
The loop
Success is observed, never assumed.
Every recovery Vigil performs is checked afterwards by the same probe that found the failure. Nothing is marked fixed because a request returned 202.
-
A probe fails:
checkout-service, three vantage points, 3 of 3 agree. -
Down past its threshold. The incident opens itself: severity set, timeline started.
-
Before acting, the worker probes once more. The failure is real.
-
A signed trigger fires at your restart hook.
202. -
Probed again:
200in 184 ms. Verified. The incident resolves.
Every one of those bounds is a field, not a promise: how many attempts an incident may spend, how long to wait between them, and how long to wait before checking whether it worked.
recovery, per monitor bounded before it is allowed, and off until the last toggle is on
And when it loses, it loses well.
The incident at the top of this page is the demo's own, and it is a failure of recovery: the hook fired twice, verification failed twice, recovery stood down and paged a human. A restart cannot fix a missing DNS record, and nothing here pretends otherwise.
The inventory
Everything it speaks to.
42 check types, and they are protocol adapters rather than integrations: one request, one answer, run from hosts you control, with nothing installed on the target.
- http
- tcp
- udp
- ping
- dns
- tls-expiry
- domain-expiry
- websocket
- grpc
- smtp
- imap
- ftp
- ssh
- sip
- ntp
- ldap
- radius
- snmp
- postgres
- mysql
- sqlserver
- oracledb
- mongodb
- redis
- memcached
- elasticsearch
- rabbitmq
- mqtt
- kafka-producer
- docker
- system-service
- real-browser
- json-query
- synthetic-api
- synthetic-browser
- gamedig
- steam
- globalping
- tailscale-ping
- push
- group
- manual
Down means duration
A monitor is marked down once it has been failing for as long as you said: a duration, per monitor, not a count of checks. Hand any check to agents on your own machines and require two of three to agree first.
How the quorum works25 native providers
Slack, Teams, Discord, Telegram, PagerDuty, ntfy and the rest, plus anything else through your own Apprise server, plus member email, SMS and voice through your own Twilio account.
Every provider15 monitoring systems
Imported over their own APIs and from an Uptime Kuma database file. Previewing is a real import that was rolled back, and what cannot be carried faithfully is refused rather than approximated.
What a move carries
monitors sixteen checks, four protocols, one of them failing
Operations
Monitoring starts the record. People finish it.
A runbook runs bounded steps against the incident, suspends when a step needs a person, and verifies what it did by reading observations back. The work it hands over becomes a task with a deadline and an owner, and the answer that came back is stored beside the step that asked for it.
Objectives measure the same observations the incidents came from, so an error budget and an uptime page cannot disagree, and the status page carries the words your responders already wrote.
objectiveon call, on a phone
operations inbox one task is holding a runbook run open, and the run resumes when the task does
Migration
Run both before you trust one.
Import over a read-only token and the monitors that arrive can observe in shadow: they check, they open incidents and they build a comparison record without paging anybody, firing automation or publishing to a status page. You decide from two records of the same window rather than from a promise.
Credentials are never copied out of the old account, and a browser journey or a k6 script is refused rather than approximated, because a Vigil journey is typed steps and a script that uses loops has no honest translation.
import every source, and the rule that refused each field
Agencies and MSPs
Monitoring is a service you can sell.
One install serves every client: isolated tenants, branded status pages on your domain, roles for your team, one license covering all of it. Adding the next client does not change the bill.
A client sees their own organization and nothing else: their monitors, their incidents, their status page on your domain, under roles you set. They never receive a license of their own, and the ones who need their own deployment are the only case the license prices separately.
Point clients to a live answer instead of assembling an update by hand. Responders keep working from the same incident record.
At the end of the month the same install produces a branded report with that client's own numbers in it, ready to send.
status pageyour domain, your client's page
client report, July 2026 your studio's name, your client's numbers
Three ways to run it
Pick the operating model first.
The interesting question is not which tool has more check types. It is who runs the probes, who keeps the history, and who is allowed to change the software.
Free, and complete
Vigil Core
Apache-2.0, self-hosted, no license key and no telemetry. Forty of the check types, incidents, incident evidence, status pages with subscribers, four team roles, the audit page and the observation ledger. One organization per install.
It is a serious monitoring system on its own, and for a team watching its own infrastructure it may be the whole answer.
What Core ships$149 once, per company
Vigil Commercial
The same code with the operational and ownership layer on top: many client organizations in one install, on-call rotas and escalation, verified automatic recovery, remote probes, objectives, runbooks, operations tasks, branded client reports, and the repository itself with full private modification rights.
You buy software rather than access to it, and every version published afterwards is included.
What the $149 coversA different model
A hosted service
Better Stack, Pingdom, StatusCake and the rest run the probes for you from their own regions and keep your history in their cloud. That is a real advantage: checks from ten locations with no infrastructure of your own, and somebody else on call for the monitoring itself.
Vigil ships software and operates nothing. If you would rather not run a server, that is the model to pick.
The figures, side by sideOwnership
The repository is the product.
$149 buys the repository: application, worker, tests, Docker, docs, full private modification rights, and every version we publish from here on. Domain logic sits behind a documented service contract so your changes survive upgrades, and schema changes ship as ordered SQL migrations.
Every commercial release becomes Apache-2.0 twenty-four months after it ships, or immediately if twelve months pass with no release at all. If this company goes quiet, the code you paid for becomes free software without anyone having to act on it. That is section 8 of the license, not a blog post.
And the free edition already exists. Vigil Core is the free Apache-2.0 edition with all 40 of Core's check types. Both editions are 1.29.0, cut from the same commit by a script that runs in a required build job.
- src/app
- dashboards, status pages
- src/modules
- monitors, incidents, notifications, recovery, runbooks, tasks, slo, synthetics, probes, ai
- src/worker
- cron tick, probes, incidents, recovery, runbooks, tasks
- src/probe-agent
- the remote probe, its own image
- src/synthetics-runner
- the browser service, its own image
- examples/
- a recovery receiver, 76 lines, no dependencies
- tests/
- 4706 tests, 1568 of them against a real Postgres
- docker/
- compose and multi-stage images
- docs/
- architecture, deployment, upgrades, customization
- vigilctl
- install, doctor, backup, update, rollback
yours after purchaseand every version afterwards
$
149
once, per company
the repository, and every version after
it