Vigil roadmap — shipped, next, not planned
A roadmap with no dates on it.
Fourteen releases behind it. Nothing ahead of it is promised.
Dates are the easiest part of a roadmap to write and the hardest to keep, and Vigil is maintained by one person. So this page states three other things: what shipped and in which version, what the product already admits it does not do, and what it is not going to become.
Fourteen releases, 1.0.0 to 1.9.1.
Grouped by theme, each with the version that delivered it. Every line below is an entry in the changelog, where the same work is written up with the bugs named.
1.0.0 · 1.5.0 · 1.7.0
1.0.0 shipped HTTP(S) monitors — configurable interval from one minute to one hour, timeout, expected status code and degradation threshold — on a Postgres-backed worker with cron fan-out, per-monitor dedup, drift-corrected scheduling and 90-day check retention, plus SSRF hardening on every target. 1.5.0 added keyword assertions: require the body to contain a string, or in absent mode to not contain one, which catches the error page that still returns HTTP 200. 1.7.0 added TCP/port checks and TLS-certificate expiry, reporting degraded when fewer than the configured days remain.
1.0.0 · 1.6.0 · 1.8.0
1.0.0 shipped incidents that open themselves on consecutive failures and resolve themselves on recovery, alongside manual incidents, severity levels, a strict lifecycle, immutable timelines and postmortems. 1.6.0 added internal notes — badged, kept on the operator timeline, never sent to the public page and never fired at the organization webhook. 1.8.0 added acknowledgement: halt the escalation ladder without pretending the incident is over.
1.2.0 · 1.3.0 · 1.4.0 · 1.4.1 · 1.4.2
1.2.0 shipped the thing the product is built around: one saved
endpoint per monitor, a fresh probe to confirm the failure is real,
a signed recovery.execute POST, then another probe, so
success is observed and never assumed. Attempts are
bounded per incident with a cooldown; the regular check loop still
owns resolution. 1.3.0 added alert holding with an exactly-once
claim and a failsafe scheduled up front. 1.4.0 added the
restart-loop guard and effectiveness stats; 1.4.1 a test trigger so
you can verify your receiver before the first real incident; 1.4.2
closes attempts a killed worker left running.
1.0.0 · 1.6.0 · 1.9.0
1.0.0 shipped a public per-organization page with live component health, 90-day uptime history and an incrementally cached render. 1.6.0 made visibility a choice — public, private to signed-in members, or password-protected with a scrypt hash and a signed, page-scoped cookie. 1.9.0 added double opt-in email subscriptions: only confirmed addresses are ever mailed, every message carries a one-click unsubscribe, and internal notes and quietly self-healed incidents never reach subscribers.
1.1.0 · 1.8.0
1.1.0 taught the organization webhook to speak Slack and Discord, detected by exact host so nothing else is misclassified. 1.8.0 shipped on-call schedules — a named rotation advancing one shift every N days from a fixed anchor — and escalation policies: ordered steps, each firing a set delay after the incident opened, targeting the on-call person, all responders or one named person, over email, SMS or voice. SMS and voice run on your own Twilio credentials; without them those steps are a clean logged no-op and the rest of the ladder still runs.
1.0.0 · 1.0.1 · 1.9.1
1.0.0 shipped multi-tenant organizations, invitations and four roles
enforced by a single permission matrix across server actions, API
and UI, plus signed webhooks, email with a structured-log fallback,
an audit trail, and an optional AI copilot on your own Anthropic key.
The two patch releases here are the honest ones: 1.0.1 fixed a container
that could not start and a Postgres volume that lost its data on
docker compose down; 1.9.1 shipped the
.env.example the ignore rule had been silently swallowing,
so a fresh clone could finally follow its own setup
instructions, and added backup, restore and troubleshooting docs.
Every dated release in the changelog falls between 3 and 11 July 2026 — Vigil is young, and the history is short and public rather than long and claimed.
Taken from the limitations, not from a wishlist.
Nothing here is a feature someone imagined. Each item is something Vigil already tells you it does not do, in a file you can read right now. No dates are promised for any of it.
Password reset is first because the product says so itself: the free edition's README calls it the top item on the list. Today a forgotten password means an admin re-invites you, which is a real cost paid by whoever is least able to fix it.
The other two are documented extension points rather than commitments. The customization guide names the exact files and the single dispatch point for each, so you can add either one yourself without waiting. What shipped so far was what agencies and MSPs asked for; that is the only prioritisation rule there is.
Where each of these would be addedThree things Vigil is not going to become.
Not a backlog nobody has reached — decisions. Where one of these is what you actually need, the alternative is named instead.
Use a hosted service
Vigil checks from the single host you run it on. A monitor going down means your Vigil host could not reach it — the consecutive-failure threshold filters blips, but this is not multi-region confirmation and the docs have never claimed it is. Fixing that properly means running probes in many regions forever, which is an operations business, not a codebase you buy once. If you need a failure confirmed from several continents with no ops of your own, Better Stack and Pingdom do exactly that; buy one of them. The advice that survives either way: run Vigil outside the blast radius of what it watches.
Different question, different data
Vigil answers whether an endpoint responded, and what the runtime did about it when it did not. It does not trace requests, profile code or index logs, and it is not growing into something that does — that needs a different storage model and an agent inside your application, and Vigil installs no agents. When a check fails and the next question is why, inside the process, that is a real APM's job and you should own one.
Nothing to call home to
No key check on startup, no phone home, not even the anonymous kind. Nothing stops working when a payment lapses, because there is no subscription to lapse — the version you hold stays licensed forever. The cost is real and it is ours: we genuinely do not know how many people run Vigil, so this roadmap cannot be ranked by usage data. It is ranked by what people say to us instead, which is the next section.
Argue with the order.
With no telemetry there is no usage graph to settle arguments, so the priorities move when someone makes a case for moving them. Maria reads both channels and answers them herself. Say what you are trying to do and what is blocking it — that is more useful than a feature name.
One thing is genuinely undecided rather than planned or refused: a hosted Vigil that Sikur runs for you. The Cloud page states the terms and takes a waitlist, and says plainly that if too few agencies want it, it will not be built.