Alerts that reach you

Set it up

1. In the Explorer, open Alarms and the Channels tab. Every account starts with one: Email to the account owner. Add another kind with New channel.
2. Press Test on the channel. The test message arrives in a few seconds, or the Explorer says why it did not - in the receiver's own words, such as 404 Not Found from hooks.slack.com: no_service.
3. On the Rules tab, create or edit a rule and tick the channels under Notify. A No data for rule starts with the account owner's email ticked; any other rule starts with none, because what is worth waking somebody for is yours to decide.

Without any rule: the quiet-source watchdog

Every account, on every plan, is told when a source stops sending - without writing a rule. A source is an API key that sends readings: your Home Assistant, a collector, a script. Once it has sent on a handful of separate occasions over at least half an hour, the watchdog watches it. When it then sends nothing for longer than it usually does, the account owner gets one email naming the key, when it last sent, a few of its tags and why the watchdog waited as long as it did. When it sends again, one more email says so. Nothing is sent in between, however long the silence lasts, and sources that go quiet in the same check - a site whose internet went down - are named in one email.

How long it waits is learnt for each source: ten times its usual gap between uploads, or half as long again as the longest it has rested on two days of the last two weeks - whichever is longer, never less than 30 minutes (or the longer wait you choose) and never more than a day. A collector that sends every few seconds is reported after half an hour; a Home Assistant that rests six hours every night is waited for nine, so its nights are not reported, and if it stops for good one evening the email comes in the small hours. In a source's first week the watchdog waits at least 12 hours, because a first afternoon of steady sending does not show whether it rests at night; a quiet first night is not taken for a stop.

One long silence is not learnt: it may have been a fault somebody fixed, or the internet being down. A rest that comes round again is, even one the watchdog wrote about - a shop whose Home Assistant is quiet fourteen hours every night is written about on its first two nights, not every night.

Time when our service is restarting, or cannot reach its own database, is not counted as a source's silence, and afterwards every source has as long again as that lasted - up to 30 minutes, or the longer wait you chose - to get through before it is written about. So while our service is unsteady, a source that really stops is reported later. An outage our service cannot see from inside - your source unable to reach our address while the service itself runs - is counted, and may bring an email that a source stopped and soon after one that it is sending again. So the watchdog tells you that a source has stopped, not that it stopped within a set time. If you need to know within, say, 15 minutes, give its tags a No data for rule: a rule waits exactly as long as you tell it to.

• A key that was revoked, or has expired, stopped on purpose: it is forgotten, not warned about. Give each collector its own key, so the email can say which one stopped.
• A source the daily quota is refusing is still sending, and is not reported as quiet: the quota email covers that.
• By default Home Assistant and the collector's OPC UA connections send a reading only when a value changes, and so does Modbus TCP on a collector older than 1.0.48 (from 1.0.48 it sends a steady value again every 5 minutes). A source whose values all stand still - at night, over a weekend - sends nothing, and the watchdog cannot tell that from one that has stopped. It learns a rest once it has seen it on two days of the last two weeks; until then it is reported, and so is a longer rest, or one of more than a day - a site closed for the weekend. If yours rests like that, make the watchdog wait longer, up to a day, or turn it off and use No data for rules with the wait you want.
• Under Settings > Mail from Tag Historian you can make it wait longer before it writes (up to a day), turn it off, and see every source it watches: when each last sent, how often it usually sends and how long it may be quiet - and, where its rests decided that, how long it has rested. At most eight of these emails go to an account in a day.
• The watchdog does not read your rules. When a source whose tags have No data for rules stops, each rule sends its alert and the watchdog sends its email, and each sends its own all-clear when the source is back. If your rules already cover every source, turn the watchdog off; if you only want one email per source, keep the watchdog and give those rules no channel, so their alerts are only listed in the Explorer.

The weekly summary

Every Monday at about 07:00 (in the time zone of the account owner's email channel, or Swedish time if it has none), accounts that have sent data in the last four weeks get one short email about the week before: the readings received against the week before that, the sources and tags that went quiet or came back, the alerts that fired, and how much of the plan is in use. Most weeks it says, first, that nothing unusual happened. It has no images and no tracked links, and every one has a link that stops it; it can also be turned off in Settings.

The channels

Each channel gets the format its receiver reads: an Adaptive Card for Teams, Block Kit for Slack, HTML for Telegram, and so on. On ntfy a critical alert has the highest priority and a warning or an error the next one; on Pushover an error or a critical alert is sent as high priority, which passes quiet hours.

ntfy works with ntfy.sh or a server of your own, on every plan. Either way it is sent ntfy's own message, the same for every account. Posting to Teams through an Azure Logic App of your own (an address on logic.azure.com)? The Teams channel does not take those; a webhook channel (Pro and up) does, and sends your Logic App the alert as JSON to do with as it likes.

A channel's tokens and URLs are stored encrypted and are never shown again after you save them - the Explorer shows the host and the last four characters. To change one, type the new value; leaving the box empty keeps the old one. An email channel's addresses are shown in full to the account's Editors and Admins, who edit them, and masked to its Viewers; the account owner's address is masked on every channel.

What a message says

Which alert, what is wrong with which tag and by how much, when, and where to look. The time is in UTC and, if you set a time zone on the channel, in that zone too. The link opens the tag's chart in Trends from an hour before the alert to an hour after it, with the moment it was raised marked, so the first thing you see is what the value did. A message about a cleared alert charts the whole episode, and one about a quiet source starts an hour before its last reading.

Critical: Freezer too warm
Freezer.Temp is -12.4 °C, above the limit of -18 °C.
Raised 2026-10-09 14:03 UTC (16:03 Europe/Stockholm)
Open in Tag Historian: https://app.taghistorian.com/dashboard?tags=Freezer.Temp&from=2026-10-09T13:03:00Z&to=2026-10-09T15:03:00Z&at=2026-10-09T14:03:00Z

When it is over:

Back to normal: Freezer too warm
Freezer.Temp is back to normal at -19.1 °C.
It lasted 1 h 23 min. The alert was closed automatically.
Back to normal 2026-10-09 15:26 UTC (17:26 Europe/Stockholm)
Open in Tag Historian: https://app.taghistorian.com/dashboard?tags=Freezer.Temp&from=2026-10-09T13:03:00Z&to=2026-10-09T16:26:00Z&at=2026-10-09T14:03:00Z

And for a source that has gone quiet:

Gateway.Heartbeat has sent no data for 15 min. The rule allows 10 min.

Readings that arrive late

A collector that loses its network keeps its readings and sends them when it is back. What that means for alerts:

• Up to 15 minutes late, every reading counts as if it had come on time, in the order of its own timestamp.
• The newest reading a tag has counts however late it is, up to seven days - as long as the collector keeps a buffer. A collector sends its buffer oldest first, a hundred readings at a time across all its tags, which can take hours; which reading is a tag's newest is known once the API key it came with has sent nothing more than 15 minutes old for a minute. Then it is the latest thing anyone knows about the tag. A door opened during the outage raises its alert a minute or so after the collector has worked through its buffer, and an alert whose value came back to normal during the outage is closed. The message says when it happened and when it was reported:

Critical: Cold room door open
Door.Open is 1, above the limit of 0.5.
Since 2026-10-09 12:01 UTC, reported 2026-10-09 12:20 UTC: the reading arrived late.
Raised 2026-10-09 12:21 UTC
Open in Tag Historian: https://app.taghistorian.com/dashboard?tags=Door.Open&from=2026-10-09T11:01:00Z&to=2026-10-09T13:01:00Z&at=2026-10-09T12:01:00Z

• Everything older than the tag's newest reading is history. An excursion that started and ended during the outage, however many uploads the buffer took, a backfill into a tag that already has newer readings, values a gateway sends twice: all stored as usual, none of them pages anybody about the past.
• A buffer that stops part-way is judged where it stopped. If the link drops again for more than about a minute while the buffer is going out, or the account reaches its daily measurement quota, the newest readings sent so far are the latest anyone knows, and are judged as such; the rest of the buffer is judged when it has gone out.
• Give each collector its own API key. A late reading waits for the key it came with to go quiet, so on a key shared with a collector still sending a day of buffer, a door waits for that buffer too.
• Silence is measured on arrival. A No data for rule counts from the last time the tag sent us anything, by our clock - a buffer of old readings arriving is a source that is talking, and a reading stamped a year ahead by a wrong clock does not make a dead gateway look alive.

A delay is counted on the readings' own timestamps, and a value that holds counts from when it arrived, never for the time it spent in a buffer. Keep gateway clocks synchronised: every reading from a source whose clock runs more than 15 minutes slow looks late, so nothing late from its key is judged until it pauses for a minute, and its alerts read as reported late.

Email to other people

Alert mail goes to addresses somebody has shown they read. The account owner's, once they have confirmed it from the mail they got when the account was created. A teammate's, once they have joined from their invitation. Any other address is sent a link first, and gets nothing until its owner clicks Yes, send me these alerts. The link works for 7 days; saving the channel again sends a new one.

Each recipient gets a mail of their own, so nobody on a list sees who else is on it, and every mail says which channel it came from and how to stop it.

A mail to an address outside the account ends with a link of its own to stop these alerts, no account needed, and carries the headers that let a mail program offer its own unsubscribe button. Once stopped, nothing more is sent to that address from the account - no alert, no new confirmation request - and the channel shows it as stopped these alerts. Only the address's owner can start them again, from the same link.

When a send fails

• Nothing is lost in a restart. A notification is stored in the same database write as its alert, and sent from there.
• A timeout, a 429 or a 5xx is retried after 30 seconds, then 1, 2, 4 minutes and so on, each wait varied a little so that a receiver that was down for everyone is not hit by every retry at once. 8 attempts in all, over about an hour. A receiver that says when to come back with Retry-After is listened to.
• A refusal no retry can change - a wrong token, a deleted webhook, a chat the bot was removed from, an address that redirects us elsewhere - is given up at once.
• A lost answer is not a second email. A retry after an answer that never came can reach a receiver that did get the first try, so a chat or a webhook may on rare occasions show a notification twice. An email is sent once: the retry tells our email provider it is the same mail.
• The Explorer shows it. An alert with a notification that did not get through is marked Delivery failed, with the reason. The channel shows its last failure too.
• It does not cost you the next alert. A rule's cooldown stops it from alerting more often than you set - but an alert whose notifications all failed to get through does not count towards it, so the next episode is sent straight away. One that was held back on purpose - past the hourly limit below, or with nowhere to go yet - still counts.

How many

An account can have 60 notifications sent in any hour, every channel together, and 30 alert emails, each recipient counted. Past that, the rest of the hour's notifications are not sent - not queued for later, which would deliver the flood an hour late - and each one says so on its alert. The alerts themselves are raised and listed as always.

The limit is there for a rule that flaps every few seconds, or a gateway that takes a hundred tags with it when it goes down. A No data for rule on the gateway itself, and a delay and a reset margin on noisy values, keep you well under it.

What leaves us, and where it goes

A notification carries the rule's name and severity, the tag's name, the value and the limit that triggered it, the time, and a link to the Explorer; a webhook also gets the alert's and the rule's ids. Nothing else from your account goes with it. Email is sent through our email provider, Resend, which processes it in the United States. Every other channel is a service you chose, used under your own account with it: ntfy, Pushover, Telegram, Slack and Microsoft each run their own, under their own terms and wherever they keep their data. We keep a record of each notification - where it went and whether it arrived - for 30 days.

No alert is sent while an account is suspended or waiting out its deletion: its measurements are not being accepted then, and a “no data” alert would only be telling you so.

Over the API

Everything above is in the API too, with a Write or Admin key. Create a channel, test it, and name it in a rule's channelIds:

curl -X POST https://api.taghistorian.com/api/notification-channels \
  -H "X-Api-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "Ntfy",
    "name": "On-call phones",
    "url": "https://ntfy.sh/<a-long-hard-to-guess-topic>",
    "timeZone": "Europe/Stockholm"
  }'

curl -X POST https://api.taghistorian.com/api/notification-channels/<channelId>/test \
  -H "X-Api-Key: <your-api-key>"

curl -X POST https://api.taghistorian.com/api/alerts/rules \
  -H "X-Api-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "tagName": "Gateway.Heartbeat",
    "name": "Gateway quiet",
    "condition": "TagStale",
    "threshold": 600,
    "channelIds": ["<channelId>"]
  }'

Leave channelIds out and a TagStale rule goes to the account owner's email channel, any other rule to none. The webhook's payload and how to verify its signature are on the Connectors page in the Explorer.