Keeping the chat quiet: rules, bundles, live count

Updated 1 October 2026 · BugsRadar team

Everyone who has wired errors to a chat has the same memory: a crash loop at 3 a.m., a phone that wouldn't stop, and a group that was muted by morning and never unmuted. An alert that fires ten thousand times is not an alert. BugsRadar keeps the chat readable in five layers, and most of them need nothing from you.

1. The package folds repeats before they leave

Repeats of the same error within a few seconds travel to BugsRadar as one request with a count, so a crash loop costs one request every few seconds, not thousands per second. The same exception seen twice by one process - logged through ILogger and reported by hand, or caught by Express and by winston - is sent once. Reports leave through a background queue; your code never waits for the network. See how events travel for .NET, Node.js and Python.

2. The live count: one message per error

The first occurrence of an error arrives at once, in full. The next ones don't bring new messages: in Telegram and Discord the count is written into the first message, without a notification, 10 minutes after it was sent, then after 30 minutes, an hour, and every 6 hours while the error continues. When a window passes without repeats, the error is closed; its next occurrence arrives as a new first message. Pushover can't edit a message, so there the count arrives as short summaries at the same moments. Prefer a message per count in Telegram or Discord too? Turn Live count off for the channel. See What you receive.

3. Bundles when the chat can't keep up

Every chat service has a pace it accepts messages at, and BugsRadar keeps to it: when Telegram or Discord asks to slow down, delivery waits. If errors are waiting in the queue - because the service asked for a pause, or because a project sent many messages within the hour - the waiting errors arrive bundled: one message, one line per error with its type, place and count, grouped by project, without stack traces. Twenty different errors in a minute are one message, not twenty.

4. Rules: not every error to every chat

Without rules, every channel of a project gets every error. On the Pro plan a channel takes only what fits its filter: a level (Warning, Error or Critical and above), modules, environments. The person on call gets Critical in Pushover; staging goes to its own Discord channel and never wakes anyone; the payments module goes to the payments team. An error that fits no channel goes nowhere, and the project's page warns you when that can happen. See Rules.

5. The chat's own controls

The alerts come from your own bot into your own group, so everything the chat can do, you can do: mute the group for an hour while you fix the cause, pin the message you are working on, move the noisy project to its own channel. BugsRadar doesn't need to reinvent snoozing; Telegram and Discord already have it, and you already know where it is.

What a bad night looks like

One full message for the new error, with the stack trace, within seconds. The same message edited with a count of 1,248 a quarter of an hour later. One bundle if three other things broke at the same time. Zero notifications after the first, until you fix it or until a new error appears. That is the whole idea.

Where to go next

Which errors reach which chat is in Rules; what each message contains is in What you receive. Channels shows what Telegram, Discord and Pushover each do with repeats.