
Why a fixed alert threshold produces false alarms
Alert me if events drop below 100 a day is a rule that works for one store, for about a month. A threshold that doesn't know your normal fires when you're fine and stays quiet when you're not.

You tolerate the first unhelpful notification. By the fifth you turn notifications off. From that moment every detector behind that channel has stopped working, including the one you built for the case you're actually afraid of.
An alerting system that sends too little has one visible failure: something got through. Someone investigates it, and the system improves afterwards.
An alerting system that sends too much has no visible failure at all. The channel goes silent in the human sense. It's still receiving, and nobody is reading it. Nothing tells you that monitoring has switched off.
1. Attach a riyal figure, and suppress below a threshold. If the financial impact sits under the level you'd act on, don't send the alert. This rule alone removes most of the noise, and it ranks whatever is left.
2. Make thresholds relative to your store's own pattern. A fixed threshold fires constantly on a small store and stays quiet on a large one, and the same store crosses between those states within a year. See why fixed thresholds fail. Seasons do the same thing: a rule tuned to ordinary quiet hours will fire through the daytime lull in Ramadan and stay silent overnight, exactly inverted. See the daily rhythm. The answer isn't disabling alerts for the season. It's thresholds relative to the recent pattern, so they adapt without anyone remembering to adjust them.
3. Let people define their own alerts. An alert the system decided to send reads as noise to whoever receives it. An alert you defined reads as your own instruction coming back to you, and it gets read for that reason.
| Alert | Why |
|---|---|
| Purchase stop | A clear, fast failure signal |
| Store-to-platform gap | Self-scaling, and catches most of the rest |
| Pacing against target | Commercial rather than technical |
Add a fourth once one of the three has earned your attention. A library of twenty alerts switched on from day one is a muted channel with extra steps.
An alert only deserves to exist if there's a response you'd actually carry out. Write the response before you enable it:
If you can't write the response, you don't want the alert. That test removes more alerts than any other.
In Flowfy, the delivered-events log with platform responses, revenue by source, and conversions delivered per destination are live, and those are what the manual check reads. Automated detectors, configurable thresholds, riyal impact scoring and self-defined alerts are on the roadmap and haven't shipped. Until they do, your alerting strategy is a fixed check in someone's calendar, which has the advantage that it can't be muted by accident.
How many alerts count as too many? If anyone has muted the channel, you passed the line a while back.
What if I miss a break because I suppressed a small alert? A small financial impact is small by definition. The trade is deliberate: you accept missing minor problems so the channel stays readable for the major one.
Can I route different alerts to different people? Yes, and you should. The media buyer and the store owner need different things, and sending both to both is where muting starts.

Alert me if events drop below 100 a day is a rule that works for one store, for about a month. A threshold that doesn't know your normal fires when you're fine and stays quiet when you're not.

Buying moves to late evening. Sessions cross midnight and the daytime lull reads like a decline. These are the settings to adjust before the month starts.

The distribution check tells you there's an opportunity. Moving it all at once eats most of it. Here are three execution rules, and what to watch afterwards.