Logs, monitoring, alerts: what you actually need
Updated 1 October 2026 · BugsRadar team
"We need monitoring" usually means four different things at once. Sorting them out takes ten minutes and saves a few subscriptions. Here is the sorting, with BugsRadar placed honestly: it is one of the four, not all of them.
Four questions, four kinds of tool
| The question | The tool | What it keeps | BugsRadar? |
|---|---|---|---|
| What exactly happened at 03:12? | Logs: files, a log server, a search over them | Everything, for as long as you choose | No. Keep your logs. |
| Is the site up right now? | Uptime monitor, health checks, heartbeat for scheduled jobs | A history of checks | No. BugsRadar can't tell you that a job never ran. |
| How often did this error happen, and is it fixed? | Error tracker: a dashboard of errors with counts, assignees and search | Every error, grouped | No. Nothing is stored. |
| Did something new just break? | Alert: a message to a person, now | Nothing | Yes. This is the whole product. |
Logs: you already have them
Every application writes logs, and every platform has a way to read them, from tail -f to a log server with search. Logs are the complete record and the place to go when you investigate. Their weakness is the one that started this page: nobody reads them until something is already wrong. BugsRadar doesn't replace them; it plugs into them. The packages hook the logger you already use - ILogger, Serilog, NLog, log4net, winston, pino, Python's logging, loguru - and send what you log at Error and above to the chat. Already on Seq? Point the same client at BugsRadar: see CLEF and Seq clients.
Uptime and heartbeats: a different failure
An uptime monitor asks your site every minute whether it answers. A heartbeat monitor waits for your cron job to check in and complains when it doesn't. Both detect absence: the thing that should have happened and didn't. BugsRadar detects presence: an error that happened and was reported. A script can tell BugsRadar that it failed, with one HTTP request, and the guides show how for cron, systemd, backups and pipelines. A script that never started can't tell anyone anything; for that you need a heartbeat.
Error trackers: when history matters
An error tracker stores every error, groups them, counts them over time, lets you assign one to a colleague and mark it resolved. It is the right tool when errors are investigated by someone other than the person who noticed them, when you need to prove a fix by watching a count fall, or when you have many customers and need to know who was affected. It is a lot of product for a team of two, and it still needs someone to open it. BugsRadar stores nothing and has no dashboard; it is built for the moment an error first appears, not for the week after. Many teams run both; see Alerts in chat instead of a dashboard.
Alerts: the part most small teams are missing
The gap in most small setups is not storage; it is the moment of noticing. Logs are written, the site is up, and the payment handler has been throwing since Tuesday. An alert closes that gap: the first occurrence of a new error, in full, in the chat you already read, and a count instead of a flood when it repeats. That is what BugsRadar does, and all it does.
What a small team usually ends up with
- The logs you already have. Nothing to buy.
- BugsRadar for the first minute of every new error, free for 2 projects and 3 channels.
- An uptime or heartbeat monitor if "is it up" and "did the backup run" keep you awake. Different question, different tool.
- An error tracker later, when history, assignees or affected customers become real questions.
Where to go next
If the gap in your setup is the moment of noticing, Get started takes ten minutes. If it is history, Why BugsRadar stores nothing explains why BugsRadar won't be the tool for that.
Next: One developer, several projects, one chat →