Alerts about an ongoing problem now appear once and update in place instead of posting a new card every time the check runs. Two separate billing alerts no longer silence each other. Small campaigns stop raising warnings that only make sense for large ones.
What changed
Three separate problems were making alerts less useful, and each one pushed in the same direction: more noise, less signal.
The first was repetition. A problem that persisted, such as a campaign running short of leads, was re-reported on every check. If the check ran every fifteen minutes and the problem lasted two days, you got nearly two hundred cards about one situation. The cards were accurate. They were also unreadable as a group, and they buried everything else.
Now an ongoing problem produces one card that updates. The timestamp moves, the numbers refresh, and the card stays in place until the problem clears. You can see how long something has been going on by looking at it rather than by counting duplicates.
The second problem was two different billing alerts sharing one throttle. Alerts are rate limited so they do not flood you, which is correct. But the limit was being applied to a shared key rather than per alert type, so a low balance warning and a failed payment notice were treated as the same alert. Whichever fired first suppressed the other. A failed payment could be silently swallowed by an unrelated low balance warning from twenty minutes earlier. Each alert type now has its own throttle.
The third was false starvation warnings. A campaign that is not sending as much as its allocation allows raises a warning, because on a large campaign that usually means something is broken. On a campaign with fifteen leads and a three per day cap, it means the campaign is small. The threshold now accounts for campaign size, so a small campaign behaving normally stays quiet.
How to use it
Open the alert centre and read it top to bottom. It should now be short enough that this is a reasonable thing to do, which was not true before.
An alert that has been sitting there for a while is a real ongoing situation rather than a stale card nobody cleared. The updating timestamp tells you it is still being checked and still true.
If you were previously filtering alerts out of your inbox or ignoring the alert centre because of the volume, it is worth turning that filter off and giving it a week. The signal to noise ratio is different now.
Why it matters
An alert system that cries wolf gets ignored, and an ignored alert system is worse than none at all, because it creates the impression that problems will surface on their own when they will not.
The billing throttle collision is the sharpest example. A failed payment is one of the few alerts where a delay has a direct cost: sending stops, campaigns stall, and prospects who were mid sequence go cold. Having that alert suppressed by an unrelated low balance warning meant the one message you most needed was the one most likely to be dropped.
The starvation false positives were quieter in their damage but broader. They mostly affected small campaigns, which are usually test campaigns, which are usually run by people new to the product. Their first experience of the alert centre was a wall of warnings about a campaign that was working exactly as configured. That teaches people to ignore alerts on day one.
What you will notice
Fewer cards, and the ones that remain mean something. A problem that lasted a day used to leave dozens of cards behind and now leaves one.
If you had built a habit of scrolling past the alert centre, you will notice the list is now short enough to scan. If you archive alerts as a routine, you will have less to archive.
The alerts themselves are unchanged in what they detect. Nothing has been switched off. The same conditions raise the same warnings, and the checks run just as often. What changed is how many times you are told about a single situation, and whether one alert can hide another.
If you are still seeing repeats
A repeated card for what looks like the same problem sometimes means two genuinely different problems that read similarly, for example two separate campaigns short of leads at the same time. Check the campaign named on each card before treating them as duplicates.
If you see the same campaign and the same problem on two cards, that is a bug. Reply to either alert and it reaches support with the detail already attached.
Why throttling by type matters more than throttling by volume
The obvious way to stop alert flooding is to cap how many alerts you send in a period. That is what was happening, and it is the wrong shape.
A volume cap treats all alerts as interchangeable, so the ones that arrive are whichever fired first rather than whichever matter most. During a genuinely bad hour, when several things are wrong at once, that is exactly backwards. The alerts most worth seeing are the ones most likely to be crowded out, because a bad hour usually starts with a lot of low priority noise.
Throttling per alert type fixes the ordering problem without giving up the protection. Each kind of alert is limited on its own, so a chatty low priority check cannot consume the budget that a rare high priority one needs. You still do not get flooded, and you stop losing the important message to the unimportant one.
What to do with a long running alert
An alert that has been updating for days is telling you about something that has not been resolved, and the updating timestamp is now the useful part of it.
Look at whether the numbers on the card are moving. A lead shortage where the count is falling is a campaign working through the last of its list, which resolves itself. A lead shortage where the count has not moved in three days is a campaign that has stopped, and the reason is somewhere else.
That distinction was impossible to make when every check produced a new card, because the history was buried in duplicates rather than visible on the one card that mattered.