Alerts in chat instead of a dashboard
Updated 1 October 2026 · BugsRadar team
An error tracker answers "what has been happening". An alert answers "something new just broke". They look like the same product and are not, and a small team usually needs the second before it can afford the first.
Two jobs that look like one
A dashboard collects errors, groups them, counts them, lets you assign them and search them. To get anything out of it, somebody has to open it, and to open it at the right time, somebody has to be on duty. In a team of twenty that is a rota. In a team of two it is nobody, most of the time.
An alert does one thing: it puts the first occurrence of a new error in front of a person, now, in the place that person already looks at. It needs no duty and no habit. It also keeps nothing: once the message is in your chat, the alert has done its job.
What the chat does instead
- The message is the record. The first occurrence arrives in full, with the stack trace. Repeats are counted in that same message, so the message of an error is also its running total.
- Bundles keep it readable. When errors come faster than the chat accepts, they arrive bundled: one message, one line per error, grouped by project.
- Rules route. On the Pro plan a channel takes only the errors that fit its filter: critical ones to the person on call, staging to its own channel, one module to the team that owns it. See Rules.
- The chat's own tools apply. Mute the group for an hour, pin a message, reply in a thread, forward it to the person who knows. You already know how.
What that costs you
No history. BugsRadar stores nothing, so there is no page of last month's errors, no trend line, no search. If a question starts with "how often did this happen in August", the chat won't answer it; your logs or a tracker will.
This is a trade, not an omission. Not storing events is what makes the Free plan possible without event quotas, what keeps your users' data off our disks, and what keeps the product small enough for one person to understand in an afternoon: see Why BugsRadar stores nothing.
When you need both
You need a tracker when errors are investigated by someone other than the person who received the alert, when you need to prove a bug was fixed by watching its count go to zero over a week, or when you ship to many customers and need to know which ones were affected. Teams in that position run a tracker and BugsRadar side by side: the tracker for the investigation, BugsRadar for the minute the error first appears. The two don't compete for the same minute.
Where to go next
See what the messages look like in What you receive, or read Silent failures for the problem this solves. The Pricing page lists what Free and Pro include.
Next: Why BugsRadar stores nothing →