Monitoring

Monitoring continuously evaluates your devices and their readings against rules you define yourself and records every alert state detected this way as an incident — from occurrence through acknowledgement to resolution. In the App section under "Monitoring" there are four tabs for this: Live, Rules, Incidents and Maintenance.

Live — the status overview

The Live tab shows at a glance how your devices are doing: every device with an open message appears with a coloured marker for the highest severity currently reached. If everything is fine, the list stays empty.

The same overview is also shown by the "Live status overview" widget on your dashboard, if you have displayed it there.

Rules

A rule defines what is to be monitored: a target (a single device or a whole device group), a condition, a duration and a severity. As soon as the condition is continuously true for the set duration, an incident arises from it.

+ New rule opens a form that guides you step by step (or, if you like, with the rule wizard entirely without prior knowledge) through the settings: choose device or group, choose condition, set duration and severity, assign a name.

Condition types

• Threshold of a metric — the most common condition: a metric (e.g. the temperature) is checked against a value with a comparison operator (>, <, ≥, ≤, =, ≠), e.g. "Return flow temperature > 15".

  

• Device offline — triggers as soon as a device stops reporting. Needs no further details.

• Multiple conditions (AND/OR) — combines two or more of the above conditions: with "AND" everything must apply at the same time, with "OR" a single one is enough.

• Rate of change — triggers when a metric has changed by at least a certain amount within a time window, e.g. "Return flow temperature falls by at least 2 within 10 minutes". Useful for detecting a sudden drop or rise before a fixed threshold is even reached.

  

All condition types share the same duration setting: it must be met continuously before an incident arises at all — a single brief outlier in the reading therefore does not trigger an alarm yet.

Severities

• 🔵 Info — informational, no immediate action needed.
• 🟡 Warning — should be watched.
• 🔴 Critical — needs attention. At this severity a short reason is additionally mandatory when acknowledging as well as when resolving an incident — with info and warning it remains optional.

Rules for device groups

If a rule targets a device group instead of a single device, it applies automatically to every current and future member of this group — each member device is evaluated independently of the others, so a single conspicuous device opens its own incident without affecting the other group members. New devices added to the group later are monitored automatically — the rule does not have to be adjusted for this.

A group-wide rule can only be created, changed or deleted by the group's rule admins; all other members only see it. For a rule on a single device the following applies: visible to everyone with access to this device, editable or deletable only by the person who created it.

Incidents

An incident is an alert state established by monitoring — not an alarm in the sense of a notification, but a pure fact: "this rule was violated from this point in time to that point in time". Each incident goes through its own lifecycle:

• Open — the condition is currently true.
• Acknowledged — someone has taken on the matter. The condition may still be true, but the incident stays open — "acknowledged" only marks that it was not overlooked.
• Resolved — either the condition is no longer true on its own (detected and closed automatically), or someone has closed the incident manually with a reason, for example because a sensor was obviously defective and there is no need to wait for an actual recovery of the reading.

As described above, a reason is mandatory at severity critical both when acknowledging and when resolving; optional for info and warning.

For a group-wide rule, the Device column always shows the specific member device that actually violated the condition — not the group itself.

Maintenance — planned downtime without false alarms

Sometimes a conspicuous reading is expected — for example during maintenance work or a planned restart. So that this does not count as a real alarm, a device or a whole device group can be muted for a time window in the Maintenance tab.

With + New maintenance window you specify whether a device or a group is affected, when the window begins (default: now) and whether it ends at a specific point in time or is open-ended — that is, runs until it is cancelled manually. A reason is optional but helps with traceability later.

A mute on a single device also takes effect if this device is a member of a group (which itself is not muted) — this makes it possible to specifically hide a single conspicuous group member without muting the whole group.