Skip to main content
12 September 2026 · The Hive team
Every team that has set up alerts knows how it ends. The first week, people read them. By the third, a filter sends them to a folder. By the second month, the one alert that mattered sits unread next to two hundred that did not. The problem is not that teams are careless. It is that most alerts are not worth reading. An alert earns attention only if it is right often enough, explains itself, and gets better when you tell it it was wrong. This post walks through the design choices that get you there — the ones we made for Signals in Hive, and ones you can apply to any monitoring you build.

​
Why thresholds fail

The classic alert is a threshold: tell me when overdue invoices exceed £10,000, or when support tickets exceed 50 a day. Thresholds fail in two directions at once.
  • Set too low, they fire on normal variation. Month-end, a campaign, a holiday — and the alert is wrong again.
  • Set too high, they stay quiet until the problem is large.
  • Set once, they rot. Your business grows, your normal moves, and nobody updates the number.
A static line cannot describe a moving business.

​
Learn what normal looks like

The alternative is to learn a baseline for each metric from its own history and ask whether today is unusual for this metric. Two details matter more than the choice of algorithm. Use robust statistics. Averages and standard deviations are dragged around by the very outliers you are trying to detect. Hive’s trend detection uses the median and the median absolute deviation, which barely move when one bad week appears in the history. Require the breach to persist. A single spike is usually noise: a batch import, a late sync, a one-off refund. Hive only counts a trend breach when a reading is well outside the baseline (a robust z-score of 3 or more) on at least two of the last three readings. One odd point never fires on its own. The cost is a short delay; the benefit is that a signal usually means something is really happening. Baselines also need history, so a trend metric starts in a Learning state until it has enough readings (five, in Hive). That is visible, not hidden — which brings us to coverage.

​
Make silence meaningful

An empty alert feed is ambiguous. It could mean everything is fine, or that nothing is being watched. Those are very different situations. So Hive shows Coverage next to the feed: for every connected tool, what is being watched, and whether each metric is Watching, Learning or Paused. The page says plainly that an empty feed is not an all-clear — Hive can only raise what it observes. If you do one thing to your own monitoring after reading this, add that view. See Coverage.

​
Show the evidence, not just the verdict

“Anomaly detected on account X” is a verdict. It asks you to trust the detector. A useful signal shows its working:
  • Readings — the actual values, typed as money, counts, days or dates, with a comparison such as “against your usual”.
  • The source — which tool and which field the reading came from, with a link back to the record.
  • Why it matters and what is at stake — the amount at risk, how many people are blocked, the deadline.
  • Confidence, labelled honestly — Hive distinguishes a confidence it measured from the model’s own estimate, and says which one you are looking at.
  • A prepared next step — and a clear statement of whether anything has been sent.
With that in front of you, deciding takes seconds, and a wrong signal is obviously wrong. See Trustworthy signals for the full anatomy.

​
Rank by what matters, group what belongs together

Not every true signal is equally important. Hive orders the feed by stage first (does it need you, is Hive already on it, is it only being watched), then by severity, then by a score that combines severity, confidence and the business value of what is affected. A repeat of a signal you have already seen updates the existing row — “seen 2m ago · 47th time” — rather than creating 47 rows. Related signals that fire together collapse into one row with a count. That last point matters most on bad days. When one upstream problem causes twenty downstream symptoms, you need one row, not twenty.

​
Let every “no” teach the system

This is the part most monitoring gets wrong. When you dismiss an alert, the system usually learns nothing, and it fires again tomorrow. In Hive, dismissing asks why, and each answer does something different:
  • Already handled or Duplicate — stay quiet about this particular record.
  • This is expected — mute this type — stop raising this type for the workspace for a while (Admins and Owners; 14 days by default, up to 90).
  • Not relevant to us or Wrong — this isn’t happening — count towards fatigue for the type.
  • The underlying data is wrong or Wrong record — flag the connection behind it for a look, rather than blaming the detector.
  • Just dismiss it — close it, change nothing.
Fatigue is automatic and reversible: once enough signals of a type have been surfaced recently and most of them were dismissed, that type stops notifying, and it comes back on its own as those dismissals age out. See Triage signals.

​
A checklist for your own alerts

Whatever you monitor with, these questions will tell you whether your alerts will still be read in three months:
  1. Is each alert compared with that metric’s own normal, not a fixed number?
  2. Does a single data point ever fire an alert on its own? (It should not.)
  3. Can you see what is being watched when the feed is empty?
  4. Does each alert show the underlying readings and a link to the source?
  5. Are repeats and related alerts grouped?
  6. Does dismissing an alert change what fires next?
  7. Is there a cheap way to say “the data is wrong” that does not blame the detector?
Alerts that pass all seven are rare. They are also the only kind a busy team keeps reading.

How Hive builds trustworthy signals

Evidence, provenance and coverage in detail.

Triage signals

Act, snooze and dismiss — and what each teaches Hive.