Silent failures: the errors nobody reads in the logs

Updated 1 October 2026 · BugsRadar team

The error was logged. The line is right there, with a timestamp and a stack trace. Nobody read it, because nobody reads logs until something is already on fire. The first signal came from a user, a week later, in an email that started with "I'm not sure if this is the right address".

How a failure goes silent

It is rarely a crash. A crash is loud: the process dies, a health check fails, someone restarts it. The failures that go silent are the ones the code survives. A payment webhook throws, the handler catches, logs and returns 500; the shop keeps running, the order is never confirmed. A nightly import fails on one row and finishes "successfully". A background job throws the same exception every five minutes, and the log grows by a few megabytes a day that nobody opens.

Logging is doing its job. The log is complete. The gap is between the log and a person: there is no moment when the line is put in front of somebody who can act. Writing logger.LogError feels like handling the error. It is handling the record of the error.

Why a dashboard doesn't close the gap

The usual answer is a dashboard: a place where errors are collected, grouped and counted. It is a good answer to a different question - "what has been happening" - and it works for a team that has someone on duty to open it. For a small team or a solo developer, a dashboard is one more tab that is not open. The error is now in two places nobody is looking at instead of one.

What closes the gap is a message that arrives where you already are, at the moment the error first happens, with enough detail to decide whether to drop what you are doing.

What changes with an alert in the chat

• The first occurrence arrives at once, in the Telegram group, Discord channel or Pushover app you already read: the project, the level, the exception and its message, where it happened, the environment, host and version, the properties and the stack trace. See What you receive.
• The next occurrences don't arrive. They are counted in that same message. A job that fails every five minutes is one message with a count, not a flood you learn to ignore.
• A new error looks new. When an error stops and comes back a day later, it arrives as a fresh first message, so a regression after a deploy isn't buried in last week's thread.

None of this replaces the log. The log keeps the history; the alert makes sure the history isn't the first place you hear about it.

Ten minutes to the first alert

Create a project and a channel in the web app, then add the package for .NET, Node.js or Python: everything your application already logs at Error and above goes to the chat, and uncaught exceptions with it. A script that isn't an application sends one HTTP request: see the guides for cron, backups, CI/CD and SQL Server Agent.

What it won't do

BugsRadar keeps no history and has no dashboard. The message in your chat is all there is; nothing is stored on our side. If you need to search last month's errors, keep your logs or add an error tracker next to BugsRadar. The point of BugsRadar is the first minute, not the archive.

Where to go next

Alerts in chat instead of a dashboard explains the division of labour. Keeping the chat quiet shows how a crash loop stays one message. Or go straight to Get started.