Services and Monitoring
Monitored services with live status; the detail panel shows uptime (24h / 7d / 30d) and recent outages.
Track the services each host runs, watch them (and the hosts themselves) go up and down, and see uptime history.
The Services tab lists services per host — name, host, port/protocol, status, optional URL and icon. Add them with + Service, or ⊕ Bulk to add several (e.g. a host's containers) at once. Tick rows → Delete selected to remove in bulk.
Each service links to a host, so Boltarr always knows which machine runs it.
Turn on monitoring for a service (tick Monitor in its detail panel, or open the full editor with ✎ Edit) and Boltarr probes it on a timer. Pick how it's checked:
- HTTP(S) → a GET to the service's URL. Any response counts as up — even a 404 or 403; only a connection error, timeout, or TLS failure is down. Redirects are followed and certificate errors are ignored.
- TCP → a connection test to a port. The port accepting the connection = up.
- Ping (ICMP) → is the target IP reachable (does it reply to a ping). Handy for a device or container with no useful port or URL — but it's reachability only, it doesn't prove the service itself works.
Check target. TCP and Ping probe an IP that defaults to the linked host, but you can override it (the "Monitor target IP" field in the edit dialog) — so a service can run on host A while its check points at a container's own IP. HTTP uses the URL. The probe runs from wherever Boltarr runs, so the target must be reachable from there. (Tip: a URL by bare IP fails if the server does hostname/vhost routing — use TCP to the port, or a URL the server actually answers.)
The probe interval is configurable in Settings → 📱 Notifications — "Probe each service every N seconds" (15–600s, default 60). A longer interval is lighter but slower to notice an outage (detection is accurate to about ±the interval, and a blip shorter than it can be missed); the down-alert grace can't fire faster than one probe. This interval also sets the width of one tick on the status page's 1-hour bar (one tick per probe).
Results:
- A live up/down dot in the services table (flips on the first failed check). The monitor's verdict can also drive the service's shown status (running/stopped).
- Uptime % for the last 24h / 7d / 30d + a list of recent outages, in the detail panel. History is kept ~31 days and pruned automatically. You can reset a service's uptime baseline from its detail panel to start its history fresh.
-
Alerts (via Notifications): a down alert fires once a service has been continuously down past the grace period (
alert after service down for), and a recovery alert when it comes back. Quiet hours are respected.
A light background ping sweep (nmap -sn) marks every known host online/offline — the dot next to each IP. Configure it in Settings → 📡 Liveness (sweep interval, offline-after threshold).
- A host goes offline after a few consecutive missed sweeps, back online on the first response (brief blips don't false-alarm).
- Transitions record a change event and — for static hosts, unless opted out — fire an immediate, quiet-hours-aware alert.
- Host uptime: a host's Edit → Info → Liveness section shows its up/down + 24h/7d/30d uptime % + outages, just like services.
Because services know their host, Boltarr connects the dots:
- Each service row shows its host's up/down.
- A down service whose host is offline gets a "host offline" tag — instant root cause ("why are 8 services down? → the server's down.").
- Alert suppression: when a host goes offline, its services' individual down-alerts are held, so you get one host-offline alert instead of a flood. Toggle in Settings → 📱 Notifications (on by default).
Mark services (and hosts) public to show them on an external status page — see Public Status Page.