An action rule says who is told, how, and about which states: CRIT to the on-call phone, WARN to the team's Matrix room, a ticket for anything critical. Rules are made under Setup, Actions. This panel is where a rule is attached to a place in the tree, so it knows what to watch.

Binding a rule

• Choose the rule and bind it. With And everything beneath ticked, which it is by default, the rule covers this object and everything under it: bind once on a site and every device and sensor in it is covered, including ones added later.
• On a sensor, a binding covers that sensor only.
• The top of the estate cannot be bound. Bind to each site instead.
• The panel lists the rules bound here, and under Reaching here from above the ones that cover this object from a binding higher up. An object can be covered from above without anything bound on it.
• Unbinding stops the rule watching this object from its next message on. Anything still covered by a binding higher up stays covered.

More than one rule

• The same rule reaching an object by two bindings, say one on the site and one on the device, still lists it once.
• Different rules each send their own message. That is how escalation works: a WARN and CRIT rule to the team's chat room, and a CRIT only rule to the on-call phone. It also means two rules with the same recipient give that person two messages.

What sets a rule off

• A change of state into one the rule is about: WARN, CRIT, UNKNOWN (no verdict can be reached) or STALE (nothing is reporting at all). Moving between them counts too, so a WARN and CRIT rule tells you when a warning becomes critical.
• A recovery. When something leaves the rule's states, the next message reports it as cleared. Something that failed and recovered before anyone was told is dropped quietly.
• Only changes. Something already failing when you bind a rule, or switch it on, is not announced until its state next changes.
• A state that flips and flips back within the same minute is not reported.

When messages go

• There is no delay on the rule itself. What stops a single blip raising an alarm is the sensor's failure threshold on its Polling panel, and its Rollup settings. Rules are checked every minute.
• One message per rule, listing everything that rule has open, worst first, with what is new marked as such. When a sensor fails and takes its device and site into alarm with it, all of them are in the one message.
• Depth, set on the rule, decides how far down the message names things. At device depth, three failing sensors on one server appear as the server, with 3 sensors beneath it. A rule for managers might list sites; one for engineers, sensors.
• Repeats. The rule's number of sends and interval decide how often an alarm is repeated while it lasts. Acknowledging the alarm under Current alarms on the dashboard stops the repeats; a change of state is still sent.
• Charts go with alarms on email, Matrix and tickets, for sensors with Charts in notifications ticked on their Polling panel.

Quiet times

• A rule with a schedule sends nothing outside it. When the schedule opens, one message goes with whatever is still wrong, and clearances for anything that recovered meanwhile.
• An object that is paused, suspended, still a draft or outside its own schedule raises no new alarms. Pause a device before maintenance, rather than unbinding its rules and trying to remember to bind them again.

Channels

Messages are laid out by templates, also under Setup, Actions. Each channel has a built-in one, so a template is only needed to change the wording.

Testing

Use Test on the rule under Setup, Actions. It sends a sample message to the rule's recipients straight away, whatever its schedule and bindings. Do not test by breaking something: every rule covering it will fire, to everyone on them.