Every email and text message sent by an Alert Rule combines alert details generated by Device Health with the Subject and Message configured in the rule. Knowing which part comes from where makes it easier to configure a Message that adds information rather than repeating what the notification already carries.
The three parts of a notification
| Part | Source | Purpose |
|---|---|---|
| Alert details | Generated by Device Health | Identifies the alert, which device triggered it, and its state |
| Subject and Message | Alert Rule settings | Instructions the alert details cannot supply |
| Response link | Generated by Device Health | Lets the recipient acknowledge or resolve the alert without signing in first |
The parts arrive in that order: alert details first, the action's Message next, then the link. Subject applies to email only.
The alert details Device Health supplies
Alert details are built from the alert itself, so they are always current and cannot be edited. They identify:
- The Alert Name from the rule, so recipients can tell which rule sent it
- Which device triggered it — its name with its MAC address, or the device model and MAC address
- Where it is installed, as a location path: campus, building, floor, and room
- The battery level or offline state that triggered the alert
Device Health's rule types do not add an opening sentence of their own, so the notification begins with the Alert Name. A name that states the situation — Portal Lights Offline — North Campus — tells a recipient what happened before they read anything else.
Examples by rule type
The examples below show the alert details only. The action's Message follows, then the response link.
Battery level
Asset Tag Battery Low triggered by Asset Tag 4471 (D1:2A:3F:4B:5C:6D) in North Campus > Main Building > Floor 2 > Storage. Asset Tag 4471 has battery level 12%.
Portal Light offline
Portal Lights Offline — North Campus triggered by Portal Light (D1:2A:3F:4B:5C:6D) in North Campus > Main Building > Floor 2 > Corridor. Portal Light (D1:2A:3F:4B:5C:6D) is offline.
Portal Light offline, by threshold
A threshold rule reports how much of the group is affected rather than naming one device:
Portal Lights Offline — Threshold triggered in North Campus > Main Building. 15% of devices are offline.
Depending on how the rule is configured, this reads as a percentage or as a count of devices.
How each action delivers it
| Action | What the recipient gets |
|---|---|
| Emails | The action's Subject as the email subject. The body carries the alert details, the action's Message, and the response link. When Subject is empty, the email is sent without one. |
| Text Messages | One message containing the alert details, the action's Message, and the response link. A short Message is better — long text is split by the recipient's carrier. |
| Webhooks | The alert as structured data for the receiving system to process. The payload is defined by the webhook itself in Company Settings, not by the Alert Rule — it carries whichever built-in variables the webhook's template uses. See Webhook built-in variables reference. The action sets only which webhook to call, so a Subject or Message written on another action never reaches it. |
What makes a useful Message
A Message belongs to the action it is set on, not to the rule as a whole — Emails and Text Messages each take their own. Whichever action carries it, the same text is sent for every alert that rule triggers. The alert details change with each alert; the Message does not. It therefore has to hold true for every device and location the rule covers.
That rules out anything specific. A Message naming one device or location will be wrong for most of the alerts it is sent with, and it duplicates what the alert details already provide.
What works instead is a standing instruction — the procedure to follow, and who to contact:
- Effective: "Confirm the device has power and that the area has Wi-Fi coverage, then raise a ticket with IT referencing this alert."
- Less effective: "The Portal Light in the Floor 2 corridor is offline — reboot it" — the alert details already carry those specifics, and they are wrong for everything else the rule covers.
A rule scoped narrowly can support a more specific Message, because less is in play. The broader the rule's scope, the more general the Message has to be.
Alert Rules are commonly created and maintained by several administrators, and read by responders who did not configure them. A Message therefore needs to make sense on its own:
- Name teams, departments, and extensions rather than individuals, so the Message survives staff changes.
- Avoid shorthand that only the person who wrote the rule would recognize.
- Point to a procedure the recipient can follow without knowing which rule sent the alert or who set it up.
The same reasoning applies to the Alert Name, which recipients see first and other administrators rely on when reviewing rules. A consistent naming convention — location, alert type, and who it covers — makes both the notification and the Alert Rules list easier to work with.
Note: A Device Health notification reports that a device needs attention. The device's full history and current status are in Device Management.