Operate

Using Torwarden

What each part of the product is for, and the decisions worth making deliberately rather than leaving at their defaults.

Hosts

A host page carries current state at the top and history below it. Pick a range, or drag on any chart to zoom; the crosshair is synchronised across every chart on the page, so a spike in CPU and a spike in disk I/O can be read at the same instant.

Expanding a row in the host list gives the same charts inline, which is usually enough to answer "is it just this one" without leaving the page.

Alert rules

A rule names a metric, a threshold, and how many samples have to agree. Torwarden ships with a set covering CPU, memory, swap, load, filesystem usage, free space, inodes and agent reachability, all enabled — a monitoring tool that ships with nothing configured is one nobody configures.

The settings that decide whether you trust it

• N of M. How many of the last M samples must breach. Three of five at a 30-second interval means a rule fires on a condition that has held for a minute and a half, not on one bad reading.
• Recovery thresholds. Set the clear point below the fire point. Without the gap, a metric sitting on the line produces an alert every evaluation.
• No-data policy. What a missing reading means for this rule: a problem, recovered, or ignore. Get this wrong and an alert either never fires or never clears.
• Scope. Global, by tag, or one host. Tags are the maintainable answer — a rule scoped to env:prod keeps applying as the estate changes.

Test it against history first

The rule editor replays a rule against the last 30 days of stored samples and reports how many times it would have fired, on which hosts, and for how long. Tuning a threshold against real history takes a minute; discovering it was wrong takes a week of being paged.

Alerts

Firing alerts can be read three ways: by alert, by the rule that raised them, or as history. Acknowledge to say you are on it, snooze to silence it until a time, close to end it with a reason. Bulk actions take one shared comment, which is what you want when one cause raised fifteen alerts.

Every alert can explain itself: which samples, against which threshold, in which window — and the same explainer says why an alert you expected did not fire.

Maintenance windows

Schedule a window before the work, from the Alerts page. A window can evaluate but stay quiet, or suppress entirely, and a host-level window automatically covers that host's filesystems and interfaces. Silencing after the paging starts is a worse version of the same thing, and it is the version most tools offer.

Alert quality

The quality page ranks rules by how often they fire, how often they are closed as "no action needed", and how quickly they resolve themselves. A rule that fires nightly and is always closed without action is a rule to retune — and it is invisible until something counts it.

Endpoints and certificates

An endpoint is a URL the server probes. It needs nothing installed on the thing being watched, which is the point: it covers appliances, third-party APIs and anything you do not own. HTTP status, response time, TCP reachability, and keyword matching — including the inverse, which is how you catch a maintenance page or a stack trace served with a 200.

Certificate monitoring rides on the same endpoint, because a certificate is a check you run against something you already watch, not a separate kind of thing to configure. You get chain analysis, expiry, weak-algorithm detection and optional domain expiry. Expiry warnings scale with the certificate's own lifetime, so a 90-day certificate and a two-year one do not share a threshold that is wrong for both.

Availability

Availability targets are derived from alert history — the episodes already recorded — rather than from a second measurement. A target has a scope, a percentage, a window (rolling or calendar month) and a definition of what counts as down. The default counts only reachability, because a critical CPU alert is not an outage and an availability figure that treats it as one measures whether everything was perfect rather than whether the service was serving.

Planned maintenance is excluded by default. Each target reports availability, downtime, error budget remaining and burn rate, with a day-by-day matrix.

Dashboards

Twelve-column grid, drag to place and resize, add panels from the library. Dashboards export as JSON, so one can live in version control and be imported into another instance. The shipped "Fleet health" dashboard is a starting point — clone it with Save as copy rather than editing it, so upgrades can keep improving the original.

Notifications

Channels are configured under Channels, and routed by severity and scope. Grouping coalesces a burst of non-critical alerts into one message; criticals are never held. Quiet hours hold non-critical notifications overnight in the timezone you configure, and never hold criticals or recoveries.

Users and access

Local accounts with roles — viewer, editor, admin — or an LDAP directory. Sessions are listed on the profile page and can be revoked individually. The console administrator from server.conf is a recovery credential, not a daily login; create real accounts.