One storm crossing many monitored sites, raised as a single grouped alert — not one message per location.
One storm, a hundred sites, three hundred messages
Alerting one location at a time is a long-standing default. Run the arithmetic on a single storm system crossing a footprint of a hundred monitored sites. A prior warning, a start notification, and an all-clear — per location — is three hundred messages for one weather event. Nobody reads three hundred messages.
What actually happens is the opposite of what all that thoroughness intends. The alert that should have moved someone arrives indistinguishable from the two hundred and ninety-nine that didn’t need to. People stop reading. Then they filter. And eventually the volume itself becomes the reason a team turns notifications down, or off — which is how a monitoring system fails quietly, while appearing to work.
An ignored alert is worse than no alert. It spent someone’s attention and returned nothing for it.
Fewer messages, each carrying more
Grouped alerts have been narrowing that gap for two releases now. First came the foundation: selecting every location that shares a tag when configuring an alert, and grouping their notifications — one prior, one start, one all-clear for the whole group, instead of one of each per site.
This release makes each of those messages carry more:
- Every impacted location, named. A grouped notification now lists the locations affected, each with its expected impact timing — where previously only the first was shown.
- The full list, attached. A CSV rides along with every notification, for the teams that feed their own reporting and systems from it.
- The map, one click away and already filtered. Each notification links to the map page filtered to the group’s tag, so following through takes one action, not a search.
- Updates in both directions. Alongside cancellations and earlier starts, notifications now report a delayed start and a change in duration — because an event that moves is exactly when a team needs to re-decide.
The design rule underneath all of it is easy to state and hard to build: consolidation must never cost visibility. Fewer messages only works if each one carries more — otherwise you’ve traded noise for blindness.
One scope note worth being plain about: grouping works on insight alerts, with the group defined by a locations tag. If your locations are already tagged the way your operation is organized — by region, by division, by client — the grouping follows that structure automatically.
The conversation
We’re sitting down with the team that built grouped alerts — how the proximity engine decides what belongs together, what “consolidation must never cost visibility” took to engineer, and where grouping goes from here. That conversation lands on this page.
Turn it on
Grouping is available now, in the alert creation modal, for insight alerts defined by a locations tag. If your team is monitoring at a scale where the arithmetic above sounds familiar, this is the release to revisit how your alerts are structured — and if you’re evaluating the platform, ask to see a grouped alert arrive during the demo. The difference is easiest to understand in your inbox.
← Back to the July 2026 Release overview
▽
