Every email, text message, and phone call sent by an Alert Rule combines alert details generated by Temperature Monitoring 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 Temperature Monitoring | Identifies the alert, what triggered it, and where |
| Subject and Message | Alert Rule settings | Instructions the alert details cannot supply |
| Response link | Generated by Temperature Monitoring | 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 Temperature Monitoring supplies
Alert details are built from the alert itself, so they are always current and cannot be edited. They identify:
- What kind of condition occurred
- The Alert Name from the rule, so recipients can tell which rule sent it
- What triggered it — the Storage Unit, Room, or Monitor, with its device identifier where one applies
- Where it happened, as a location path: campus, building, floor, and room
- The reading or state that crossed the threshold, for rule types where that applies
Examples by rule type
The examples below show the alert details only. The action's Message follows, then the response link.
Storage Unit threshold
Measurement threshold alert for Storage Unit detected. Vaccine Fridge 2 triggered by Vaccine Fridge 2 (D1:2A:3F:4B:5C:6D) in North Campus > Main Building > Floor 2 > Pharmacy.
Room threshold
Measurement threshold alert for Room detected. Pharmacy Ambient triggered in North Campus > Main Building > Floor 2 > Pharmacy.
Hardware error
Hardware error alert detected. Probe Fault triggered by Temp Monitor Pro (D1:2A:3F:4B:5C:6D) in North Campus > Main Building > Floor 2 > Pharmacy.
Monitor offline
Monitor offline alert detected. Monitor Offline triggered by Temp Monitor Pro (D1:2A:3F:4B:5C:6D) in North Campus > Main Building > Floor 2 > Pharmacy.
Data out of sync
Data Out of Sync triggered by Temp Monitor Pro (D1:2A:3F:4B:5C:6D) in North Campus > Main Building > Floor 2 > Pharmacy.
Note: Rule types without their own opening sentence begin with the Alert Name instead. This is why a descriptive Alert Name matters — for some rule types it is the first thing a recipient reads.
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. |
| Phone calls | An automated call that identifies itself as a Kontakt.io notification, then announces the alert details and the action's Message. The call repeats, so a missed first few seconds does not lose the alert. Whether the recipient can acknowledge the alert from the call, and how, depends on the action's Acknowledgment setting. |
| 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 for emails and text notifications
A Message belongs to the action it is set on, not to the rule as a whole — Emails, Text Messages, and Phone calls 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 Storage Unit, Room, and Monitor the rule covers.
That rules out anything specific. A Message naming one Storage Unit, Room, or Monitor 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: "Follow the temperature excursion procedure. Escalate to Pharmacy Operations on extension 4102 if the reading is still out of range after 30 minutes."
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.