Why a notification may not arrive
When a scan surfaces something serious and no notification lands, the cause is almost always one of three things: the finding sat below the rule's threshold, the destination failed to accept the delivery, or the finding matched something already reported and was suppressed on purpose.
Work through the checks below in order; each takes under a minute.
Check the threshold
Every notification rule carries a minimum severity, and findings below that floor are recorded in the interface without notifying anyone. If the rule was created with the floor set high, medium findings will look conspicuously silent. Open the rule, compare its floor against the severity shown on the finding, and lower the floor if you want broader coverage.
Remember that the floor applies at delivery time. If a finding escalates to or above the floor later, that escalation notifies even though the original discovery did not. Severity can move in either direction across scans — a widening grant raises it, a partial fix lowers it — so a finding that sat quiet for days may notify the moment its circumstances change.
Check the destination
Destinations are health-checked independently of rules. On the integrations page each destination shows its latest delivery status, and failed attempts are listed with the reason the remote side returned. The usual failures are a Slack incoming webhook invalidated by an app reinstall, an expired token on a connected workspace, and an email destination that started bouncing.
Reinstalling the app, refreshing the token or correcting the address restores delivery, and the next matching event flows through immediately afterwards. Use the test action on the destination to confirm the path end to end before waiting for a real event to prove it for you.
Dedupe is deliberate
Identical findings — same rule, same object, same state — do not notify on every scan. Without this, a single unresolved issue on a busy project would produce a message every few hours indefinitely.
Suppression lifts when circumstances change: the finding escalates or de-escalates, it regresses after being fixed, or the dedupe window configured on the rule elapses while the issue is still present. The window exists precisely because some teams want periodic reminders about known issues rather than silence; setting it shorter re-raises open findings more often.
If none of the three checks above explains the silence, send us the scan identifier and the expected rule, and we will trace the decision.
Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.