You set an alert three weeks ago. You have heard nothing. Is the market calm, or did the alert break?
This is the central problem of monitoring anything, and it is not solved by making the alert more reliable. No matter how reliable it is, silence remains ambiguous, and the human on the other end will eventually stop trusting it.
Make the system observable
The fix is to let the owner see the watcher, not just its output. A list of standing alerts with, for each one, when it was last evaluated and what the value was at that moment. If the last evaluation was four minutes ago, the silence means the market is quiet. If it was nine days ago, something is broken, and you now know it without having to guess.
This costs almost nothing to publish and it converts an unanswerable question into a glance.
Distinguish the failure modes
There are several ways an alert can fail and they need different fixes. The evaluator did not run. The evaluator ran but the data source was down. The condition fired but delivery failed. The alert was cancelled and nobody remembers doing it.
A system that reports these as one undifferentiated silence is not helping. Each deserves its own state, and the delivery failures in particular should be visible, because the alert did its job and the last mile is what broke.
The test you can run yourself
Arm an alert with a condition you know is already true. It should fire within one evaluation cycle. That tells you the whole chain — evaluation, condition, delivery — is intact, and it takes a minute. Do it after any change to your endpoint.