Suppose you ask to be told when funding on a perp goes above a threshold. It crosses. You are told. Then the condition remains true for six hours. What should happen?
The naive implementation tells you again on every evaluation cycle. If that cycle is a minute long, you have three hundred and sixty messages about one event, and by the fourth you have muted the channel — which means the next genuinely new alert is also muted. The system has defeated itself.
Three defensible answers
Fire once and retire. The alert is a question you asked once and it has been answered; it disarms itself. This is the right default for “tell me when this happens” and it is unambiguous.
Fire, then cool down. The alert stays armed but refuses to fire again for a fixed window. Useful for conditions you expect to recur and want to keep watching, at the cost of a decision about how long the window should be.
Fire on transition only. Track the previous state and fire only when it changes from false to true. Elegant, and the one most likely to go wrong in practice, because a value oscillating around a threshold transitions constantly. Thresholds that behave this way need a band around them rather than a line.
What should never happen
The alert should not silently stop working because it fired. If it retires, the system should say it retired and when, so the difference between finished and broken stays visible. A quiet alert and a dead alert look identical from outside, and only one of them is fine.
Delivery failures deserve the same treatment. If the destination refused the message three times, that is a fact the owner needs, not something to swallow.