# Vigil self-hosted status page and infrastructure alerts

> Vigil is a Rust service that probes distributed infrastructure, publishes a public status page, and sends outage notifications through several channels. It fits operators who want to self-host monitoring, but it also adds a service that must be deployed and maintained.

**valeriansaliou/vigil** — 🚦 Microservices Status Page. Monitors a distributed infrastructure and sends alerts (Slack, SMS, etc.).

- Repository: https://github.com/valeriansaliou/vigil
- Website: https://crates.io/crates/vigil-server
- Stars: 1,950 · Forks: 145
- Language: Rust
- License: MPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/valeriansaliou-vigil

## Vigil's monitoring boundary and intended operators

Vigil combines two jobs that are often handled by separate systems: internal infrastructure monitoring and a public-facing status page. Its target users are operators of distributed applications who want one service to check servers and backend applications, publish their availability on a domain such as `status.example.com`, and notify staff when availability changes. The documented alert destinations include Email, Twilio SMS, Slack, Zulip, Telegram, Pushover, Gotify, XMPP, Matrix, Cisco Webex, and Webhook.

The project is not limited to public web endpoints. According to the README, it can probe HTTP, TCP, SSH, and ICMP targets for reachability. Application services can also send reports through the Vigil Reporter library, while Vigil Local covers services that a central Vigil master cannot reach, such as systems on another LAN. This makes the scope broader than a conventional uptime landing page, but its documented checks remain focused on reachability and reported service health rather than detailed performance telemetry.

Vigil therefore fits a team that already understands its service topology and needs a compact status and notification service. It is a poor fit for an operator who does not want another application to host and maintain. The README explicitly says that Vigil must be hosted and maintained on the user's systems and points to Crisp Status as a hosted alternative. Its own status page also includes announcements, which helps communicate planned maintenance, but does not make Vigil a full incident-management system.

## HTTP, TCP, SSH, and ICMP probe architecture

Vigil begins with configured targets and repeatedly probes them. For an HTTP service, the target is contacted over HTTP; for other network services, Vigil checks TCP, SSH, or ICMP reachability. The README recommends frequent probe checks so an outage can be detected and communicated quickly. The repository dependency list supports this design: `reqwest` handles HTTP requests, `ping` supports ICMP checks, `ssh2` supports SSH, and Actix Web supplies the server-side web framework.

A service state change drives two visible outputs. First, Vigil records the changed state for its status page. Second, it can send a notification through any configured destination. That design separates detection from presentation. The monitoring core decides that a configured service is reachable or unavailable, the status page renders current and historical state for users, and notification adapters contact external systems. The README does not document retry thresholds, timing windows, regional probe distribution, or alerting escalation, so those details should not be inferred.

Application services have a different input path. The README recommends installing Vigil Reporter in an application, such as a NodeJS app, to report failures and host overload. This allows an application to provide information that a remote network probe may not detect. Vigil Local adds another path by running on a local daemon near services that the master cannot address directly. Vigil can therefore combine direct probes, application reports, and local observations, but the documentation does not state how conflicting reports are reconciled.

## Installing Vigil on Debian or with Cargo

The README offers prebuilt Debian packages and installation through Cargo. The package route is documented for 64-bit Debian 11 and Debian 12 targets, identified as `bullseye` and `bookworm`. The following commands add the Vigil Packagecloud repository for `bookworm`. The first command writes the repository definition, while the second stores its signing key in the configured keyring.

```bash
echo "deb [signed-by=/usr/share/keyrings/valeriansaliou_vigil.gpg] https://packagecloud.io/valeriansaliou/vigil/debian/ bookworm main" > /etc/apt/sources.list.d/valeriansaliou_vigil.list
```

```bash
curl -fsSL https://packagecloud.io/valeriansaliou/vigil/gpgkey | gpg --dearmor -o /usr/share/keyrings/valeriansaliou_vigil.gpg
```

After the repository and key exist, refresh the package indexes. The package should become available from the added repository.

```bash
apt-get update
```

Install the `vigil` package next. The package supplies the server, while configuration remains a separate operator responsibility.

```bash
apt-get install vigil
```

For a Rust-managed installation, the README gives one direct command. This requires Cargo and a Rust environment capable of building the project. The repository identifies the crate as `vigil-server`, while the installed executable is named `vigil`.

```bash
cargo install vigil-server
```

The README states that it was tested at `rustc 1.91.1 (ed61e7d7e 2025-11-07)`. The `Cargo.toml` declares edition `2021`, package version `1.29.0`, and the `vigil` binary entry point at `src/main.rs`.

## Configuring the first Debian package deployment

The package installation creates a prefilled configuration file at `/etc/vigil/vigil.cfg`. A first deployment starts by reviewing that file. The repository also contains `config.cfg`, but the documented package workflow directs operators to the installed file. No credentials should be added blindly: the README lists supported notification channels, while the excerpts do not show every configuration key or a complete service definition.

Edit the installed configuration through a text editor. This is the point at which an operator must define the actual target services and select the required notification behavior. The available probe families are HTTP, TCP, SSH, and ICMP. Application reports require Vigil Reporter, and inaccessible private targets may require Vigil Local. Those are distinct integration paths, not interchangeable settings.

After saving the configuration, restart the packaged service with the command documented by the README. A successful service restart starts the Vigil daemon; the excerpt does not provide a separate health-check command or a public status-page URL setting, so neither should be presented as a verified first test.

```bash
service vigil restart
```

The repository's `Dockerfile` offers a second deployment route with a separate build stage and an Alpine runtime image. It copies the `vigil` executable and static assets, exposes port `8080`, and starts the program with `vigil -c /etc/vigil.cfg`. The image expects configuration to be mounted at that path, although the README excerpt does not provide a complete Docker run command. The deployment is tied to Linux `amd64` or `arm64`, while other `TARGETPLATFORM` values cause the build stage to stop with an unsupported-platform error.

## Self-hosting costs, releases, and the MPL-2.0 license

Adopting Vigil creates an operational responsibility that its alert channels do not remove. The server must remain available if the status page is intended to be authoritative during an incident. Operators also need to maintain its configuration, TLS and domain setup, notification credentials, probe targets, and application or local integrations. The README gives `status.example.com` only as an example domain and does not document reverse-proxy or certificate procedures.

The project is not archived, and the last push was on 2026-10-10. Its recent releases include `v1.29.0` on 2026-03-26, `v1.28.6` on 2025-11-28, and `v1.28.5` on 2025-11-27. The current package manifest also declares version `1.29.0`. These facts indicate recent code and release activity, but the documentation does not publish a formal upgrade procedure, configuration migration guide, or compatibility policy for notification-provider API changes. Package operators should review each release and preserve a copy of their existing configuration before changing versions.

The repository is licensed under `MPL-2.0`. That designation applies to the project code, but this review does not assess legal obligations or give legal advice. It is relevant to adoption because organizations normally need to review license compatibility with their distribution and modification practices before deploying a self-hosted service.

## Crisp Status versus self-hosted Vigil

Crisp Status is the real alternative documented by the project. The README describes it as a direct port of Vigil into the Crisp customer support platform. Its operating model is different: Crisp hosts the status page on Crisp systems, whereas Vigil requires the adopter to host and maintain Vigil. For an organization that wants outage visibility without another self-managed daemon, that hosting difference may outweigh feature parity.

Crisp Status is also integrated with other Crisp products, including Crisp Chatbox and Crisp Helpdesk. According to the README, it can warn users through those products when a status page remains `dead` for an extended period. Vigil's documented deployment stays under the operator's control and centers on configured targets, status changes, announcements, and outbound notification channels.

Neither option's documentation in this repository establishes a comparative price, deployment-time measurement, or migration procedure. The choice should therefore follow from ownership. Choose Vigil when infrastructure ownership and control justify operating the service. Choose the hosted alternative when avoiding server administration matters more and using the vendor's customer-support ecosystem is acceptable.

## Conclusion

Operators with distributed services and a public status-page requirement should consider Vigil when they can maintain the server, configure probes, and manage notification credentials. Organizations seeking a fully hosted service, those unable to support periodic reachability checks, or teams that need deeper application telemetry should reject this design. Before adoption, verify the required monitoring and notification fields in `config.cfg`, test alert delivery in the selected channel, and confirm that the `vigil-server` deployment can run on the target operating system.

## FAQ

### How do I install Vigil on Debian 12?

The README documents a Packagecloud repository for Debian `bookworm`, followed by `apt-get update` and `apt-get install vigil`. Packages currently target 64-bit Debian 11 and Debian 12 systems.

### Which services and notification channels does Vigil support?

Vigil can probe HTTP, TCP, SSH, and ICMP targets. Its documented notification channels include Email, Twilio SMS, Slack, Zulip, Telegram, Pushover, Gotify, XMPP, Matrix, Cisco Webex, and Webhook.

### Does Vigil need to be hosted and maintained by the user?

Yes. The README explicitly says Vigil must be hosted and maintained on the user's systems. It presents Crisp Status as the hosted alternative.

## Sources

- [License: MPL-2.0](https://github.com/valeriansaliou/vigil/blob/master/LICENSE)
- [Project website](https://crates.io/crates/vigil-server)
- [README](https://github.com/valeriansaliou/vigil/blob/master/README.md)
- [Releases](https://github.com/valeriansaliou/vigil/releases)
- [valeriansaliou/vigil on GitHub](https://github.com/valeriansaliou/vigil)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/valeriansaliou-vigil