Renotification
How and when Stealed re-notifies you about an open event. Time-based and volume-based reminders.
Once an event is open, Stealed needs to decide when to ping you again about ongoing activity. Two mechanisms cover the two scenarios you'll hit in practice: time-based reminders for slow-burning incidents, and volume-based reminders for spikes.
Time-based renotification
Default cadence: 24 hours between two notifications on the same event.
After an event triggers and the initial notification fires, the event stays open. If you don't close it, Stealed sends a reminder every 24h to all attached channels.
Use this for incidents where the volume of matching leaks doesn't change much over time but you still want a daily reminder until you close it.
You can change the interval per monitor: open the monitor, edit Time-based renotification, pick another duration (1h, 6h, 12h, 24h, 48h, custom).
Volume-based renotification
Default threshold: 10 new matching leaks since the last notification.
When the count of new leaks added to an open event since the last notification reaches the configured threshold, Stealed fires a reminder without waiting for the time-based timer.
A 15-minute floor between reminders prevents bursty spikes from spamming the channel: even if 100 new leaks arrive in 5 minutes, only one reminder fires.
Use this for monitors where a sudden spike is the actual signal you care about. The default of 10 works well for most setups, but you can tune per monitor.
How they combine
Both mechanisms can be active at the same time on the same monitor. Whichever threshold is reached first fires the reminder.
Example
Monitor acme.com with:
- Time-based renotif: 24h
- Volume-based renotif: 10 new leaks
| Time | Event | What happens |
|---|---|---|
| Day 1, 10:00 | 5 leaks arrive, threshold met | Event opens. Initial notif. |
| Day 1, 11:00 | 8 more leaks arrive | Event open. matched_count=13. No notif (volume threshold not reached since last notif: 8 < 10). |
| Day 1, 12:00 | 3 more leaks arrive | Volume threshold reached: 11 ≥ 10. Volume reminder fires. Counter resets. |
| Day 1, 14:00 | 2 more leaks arrive | matched_count=18. No notif (volume not reached, time not reached). |
| Day 2, 12:00 | No new leaks | 24h since last notif → time-based reminder fires. Counter resets. |
Floors and limits
| Mechanism | Floor / limit |
|---|---|
| Time-based | Minimum 1 hour between two reminders |
| Volume-based | Minimum 15 minutes between two reminders, even if the threshold is reached again |
| Per-channel rate limit | Slack: 1 message / second per workspace; Teams: 4 messages / second; Webhook: no limit; Email: 100/hour per recipient |
If the per-channel rate limit is hit, Stealed buffers and retries. Notifications are eventually delivered but may arrive a few seconds late.
Disabling renotification
You can disable renotification entirely on a monitor by setting both thresholds to "Never". The monitor will fire the initial notification once and never re-notify, even if the event stays open for weeks.
This is useful for very low-volume monitors where any signal is enough, and you'd rather check the event manually.
What's next
- Mute a monitor: silence ALL notifications for a set window, regardless of the renotification settings.
- Deduplication: how new leaks are attributed to an open event vs. opening a new one.