Rollups
Collapse a burst of repeated events into one summary message, so a broken payment provider costs you one notification instead of two hundred.
When something breaks, the same event tends to arrive over and over. A rollup delivers the first few, quietly records the rest, and sends a single summary when the burst window closes:
⚠️ payment-failed ×200 in the last 10 min (197 rolled up)
Rollups are configured per destination, not per route — the point is to protect a particular channel from being flooded.
Turn it on
Open a destination and enable Roll up repeated events, then set two numbers:
| Field | What it does |
|---|---|
| Deliver up to | How many messages get through before the rest are collapsed (K, at least 2). |
| Per window (minutes) | How long the burst window lasts (W). |
With K = 3 and W = 10, twenty payment-failed events in ten minutes produce three real messages,
seventeen recorded-but-unsent deliveries, and one summary.
What counts as "the same event"
Events are grouped by event name, per destination. A burst of payment-failed never suppresses
your signup events, and rolling up on your Slack channel doesn't affect what your webhook receives.
What happens to the suppressed events
Nothing is lost. Every event is still accepted, stored, and counted toward your usage exactly as before — only the outbound message is withheld. Each suppressed delivery is recorded with the reason "Rolled up", visible in the event's detail view, so the history stays honest about what your destination actually received.
An event whose every destination rolled it up gets the Skipped status. That is a healthy outcome, not a failure: it means the event was deliberately held, not that a delivery broke.
Critical events are never rolled up
A rollup exists to quieten noise, and a critical event is not noise. Critical events — including the
alerts that threshold rules emit — always deliver, however many of
them arrive.
The summary message
The summary is sent shortly after the window ends, and its counts come from your delivery records
rather than from a cache, so the number you see is the number that actually happened. It arrives at
warning level with a ⚠️ icon and carries the totals in its payload.
The summary is a message about deliveries, so it does not create a delivery record of its own, and it is not billed as an event.
Window edges
Windows are aligned to the clock, which keeps summaries predictable and prevents duplicates. One consequence is worth knowing: a burst that straddles a boundary — say it starts at 12:09 with a 10-minute window — is treated as two windows, and you may receive two summaries. Longer windows make this rarer.
If a destination is deactivated or removed before its summary is due, the summary is simply dropped; the underlying events remain visible in your dashboard.