Use cases

Why alerts in a chat, who they are for, and the situations BugsRadar was built for. Short reads for the moment you decide, written by the people who run BugsRadar. No code here; that is in the docs and the guides.

Why

• Silent failures: the errors nobody reads in the logs - An error is logged, nobody reads the log, and the first signal comes from a user. What changes when the first occurrence lands in your chat.
• Alerts in chat instead of a dashboard - Two jobs that look like one: the moment something new breaks, and what happened last month. Why BugsRadar does only the first.
• Why BugsRadar stores nothing - An event stays in memory only until it is delivered. What that gives you - privacy, simpler compliance, no quotas - and what you give up.
• Keeping the chat quiet: rules, bundles, live count - A crash loop at 3 a.m. should be one message with a count. The five layers that keep the chat readable.
• Why Telegram and Discord, not email - Email alerts get filtered, batched and ignored. Why BugsRadar delivers to the chat you already read and has no email channel.
• Logs, monitoring, alerts: what you actually need - Logs, uptime checks, error trackers and alerts answer different questions. Which ones a small team needs, and where BugsRadar fits.

Who it is for

• One developer, several projects, one chat - Every project reports into one chat, with the project name on each message. What Free covers and when Pro makes sense.
• A side project that runs while you sleep - Ten minutes to a Telegram message with the stack trace, free, with nothing to pay and nothing to babysit.
• Agency: a channel per client - A project per client, a chat per client or per team, rules to route by module and environment, a key you can revoke when a contract ends.
• Maintenance after handover: know before the client does - The errors of the project you delivered reach you before the client calls; deploys as messages; the key when the contract ends.
• On-call in a group chat instead of a pager - The errors land in the team chat, someone replies "on it", and only Critical reaches the phone of the person on call.
• MVP before you have an ops team - Ten minutes for error alerts in the founders' chat, free, with no quotas to blow through on launch day.
• Internal tools nobody monitors - The admin panel, the nightly import, the report generator: one project, one chat, the first failure as a message instead of a surprise.

Situations

• Background jobs and queues that fail quietly - How workers, consumers and job runners report the first failure and count the retries.
• When their outage becomes your bug - The payment provider times out and your users see your error page. The first failure with the service, the endpoint and the count.
• Checkout errors you never hear about - The payment webhook fails, the order is never confirmed, the customer does not write. Where to report and what to put in the message.
• The first hour after a deploy - A message when the deploy finishes, the version in every error, and a regression that arrives as a new message.
• Cron, backups and services on one VPS - Every failure reported by the job itself with one HTTP request, into one chat.
• Production, staging, dev: one chat or several - Tell the environments apart, keep staging from waking anyone, and never let a staging error read like a production one.
• .NET Framework apps still in production - The packages target .NET Standard 2.0, need no dependency injection, and plug into the log4net or NLog you already have.
• Already on Seq: errors in Telegram without a new SDK - A second address in the Serilog.Sinks.Seq you already have. No package, Seq untouched.
• Go, PHP, Ruby, Java: alerts without a package - One HTTP request sends the alert: the key in a header, the text in the body. Examples in Go and PHP.
• Set it up with Claude Code or Copilot in one prompt - A coding assistant installs the package, connects it to your logging and sends a test error. What you do first and what to check.