Guide

A rule, and its wait

A rule says what counts as wrong. For says how long it has to stay wrong before anybody is told, and every rule has one.

Step by step

1. Open a server under Hosts, then one of the checks it found. The card is Rules.
2. Press Add rule, or Edit on one that is already there.
3. Metric is what is measured, Condition is how it is read — is above, is below, equals — and Threshold is the number it is read against.
4. For is the wait, and the portal says it plainly under the box: how long it must hold, mandatory on every rule.
5. Severity is one question: would you wake somebody at three in the morning for this? If yes, critical. If not, warning — it still raises the incident, it just does not ring a phone.
6. Press Save rule. A check that came from a file on the server has to be adopted first — Adopt this check — which brings it under the portal without interrupting it.

Why every rule waits

A server is not a smooth thing. The processor touches 100% while a backup runs. A disk crosses 85% and a log rotation puts it back. A service restarts in four seconds and comes up fine. A rule with no wait turns every one of those into a page, and a pager that goes off for things that fixed themselves is a pager people learn to ignore.

For is the difference between “the disk is above 85%” and “the disk was above 85%, and it still was five minutes later”. Only the second is worth a person. That is why it is not optional, and why nothing that creates a rule here — a discovery, a template, an assistant working through MCP — is allowed to leave it out.

The waits that ship are boring on purpose: about a minute for a process that has died, a couple of minutes for a port that stopped answering, five for a disk filling, ten for load, an hour for a certificate that expires in a fortnight. Anything under a minute on a sampled number is a noise generator.

The one thing people get wrong

Where to go next

Then who hears about it, and through what.

• Where alerts go
• Silences
• All the guides