Alerts — from finding out too late to knowing first

Users were losing money to failures nobody told them about.

Integrations break. That isn't the problem — the problem was when our users found out. A pipeline could fail silently and stay broken for hours, and the first signal was usually a downstream consequence: orders not syncing, invoices not issued, stock out of date. By the time someone noticed, the damage was already financial.

The platform gave them no way to act. Error handling was thin and monitoring was effectively absent, so teams were bolting on third-party tools to watch a product they had already bought. Those tools didn't understand our flows, so coverage was partial and noisy.

The reference point came from users themselves: most were already living in Grafana. That set the bar — not a notification feature, but a real alerting system with conditions, thresholds and routing.

What the system had to do

1. 01Detect, not report. Alert rules evaluate flow execution data continuously, so a failure raises a signal in minutes instead of surfacing in a weekly review.
2. 02Let users define what “wrong” means. Composable expression blocks — reduce, math, resample, threshold — so a rule matches the business risk, not a generic error count.

   

3. 03Route to where people already are. Notifications delivered to e-mail, Slack, Teams, Telegram, Google Chat or a webhook, so alerts land in the team's existing workflow.

   

4. 04Stay quiet when nothing is wrong. Recovery thresholds, silences and evaluation intervals built in from the start, because an alerting system nobody trusts gets muted.

   

How we got to the final design

We ran usability tests on the rule-creation flow — the hardest part of the product, since it asks non-engineers to express conditional logic. Testing reshaped the structure into a numbered, sequential form: name, condition, evaluation behaviour, notifications, annotations. Users could build a working rule without documentation, and without our support team.