Error Notifications & Alert Rules | Telebugs
Send the right error alert to the right place
Route production errors to email, push, Slack, Discord, Teams, or custom webhooks. Alert rules, cooldowns, muting, and spike detection keep your team focused.
Real-time notifications that surface the errors worth your time.
Quick answer: how should error notifications work?
Good error notifications should alert you when there is something to fix, not every time another duplicate report arrives. The useful workflow is: group related reports into one issue, notify on new or important changes, route the alert to the right channel, then suppress known noise while a fix is in progress.
Telebugs keeps that workflow self-hosted. You can send alerts through email, PWA push notifications, Slack, Discord, Microsoft Teams, and custom webhooks, then use rules, cooldowns, muting, snoozing, grouping, and ingest protection to keep error storms under control.
Why smart notifications matter
Error tracking without good notifications is just a fancy log file. You need to know when something breaks in production, but you also need to avoid drowning in noise. A single flaky endpoint or a known issue can generate hundreds of reports. If every one of them pings your team, people start ignoring the channel.
The goal is signal, not volume. You want to hear about new problems, spikes in known issues, or errors that keep coming back after a deploy. Everything else should be filterable or suppressible.
Telebugs was built with this reality in mind. Notifications are a core part of the product, not an afterthought or paid add-on.
Error notification channels
You can send alerts through multiple channels at once. Pick the destination based on who needs to act, how urgent the issue is, and whether the alert should go to a person, a team room, or another system.
| Channel | Best for | What the alert can include |
|---|---|---|
| Individuals, founders, small teams, and lower-urgency issues. | Error title, project, environment, links, and debugging context. | |
| PWA push | On-call developers and urgent production alerts on phone or desktop. | A concise notification that opens the relevant Telebugs issue. |
| Slack | Product and engineering rooms that already triage bugs in Slack. | Rich webhook messages using modern block-based formatting. |
| Discord | Indie teams, open-source projects, agencies, and community-run products. | Webhook messages with useful issue details and links. |
| Microsoft Teams | Organizations that coordinate production work in Teams channels. | Formatted Teams notifications for production error triage. |
| Custom webhooks | Internal bots, incident tools, ticket creation, and custom automation. | POST payloads with error message, location, links, and template-controlled details. |
You control which channels are active per project and per rule. No need to send every production error to every possible destination.
Alert rules that cut the noise
The real power comes from notification rules. Instead of sending everything, you define exactly when an alert should fire.
| Rule type | Use it for | Typical channel |
|---|---|---|
| New errors | A brand-new grouped issue appears in production. | Slack, Teams, Discord, or email. |
| Recurrences | A resolved issue comes back or a quiet problem starts happening again. | Team channel plus the issue owner. |
| Spikes | A known issue suddenly gets louder after a deploy, traffic change, or provider outage. | Push notification, team channel, or webhook. |
| Every occurrence | Rare critical paths where every single event deserves attention. | Webhook or a dedicated urgent channel. |
| Frequency and cooldown | Prevent repeated alerts from the same issue during an incident. | Any channel that would otherwise get noisy. |
Rules can be scoped to specific projects, error patterns, or environments. You can also temporarily mute or snooze an error (1 hour, 4 hours, 8 hours, 1 day, or 3 days) directly from the UI when you know a fix is in progress.
Configure precise notification rules so only the important signals reach you.
Routing patterns for real teams
A useful notification setup usually has more than one rule. You want quiet defaults, a clear urgent path, and enough context that the person receiving the alert can decide whether to fix, mute, assign, or investigate.
- Production only: route production errors to Slack or Teams, but keep staging and preview environments in email or a low-noise channel.
- Critical flows: send checkout, billing, signup, and API-auth errors to push or a dedicated webhook.
- Background work: send queue, cron, import, and webhook handler failures to the team that owns that subsystem.
- Known noisy issues: mute, snooze, or adjust grouping instead of training people to ignore the main channel.
- Deploy regressions: combine release metadata with new-error and spike rules so a bad build is visible quickly.
For the issue-shaping side of this workflow, see error grouping. For readable frontend frames after a deploy, pair alerts with releases and source maps.
How it feels in practice
A developer deploys a React app. A new error starts appearing from a bad API response in a specific component. The team gets one clean Slack message with the stack trace, context, and a direct link. No flood of 47 identical emails.
If your team uses an AI coding tool, that same alert can become a starting point: connect Telebugs through MCP error tracking, then ask your editor to inspect the error group, reports, backtraces, and breadcrumbs before you open a fix.
Later the same day the error rate jumps 10x after a marketing campaign. A spike rule fires and pings the on-call person via push notification on their phone.
A known flaky test error that the team has decided to live with for now? Mute it for 3 days while the fix is scheduled. Everyone stays focused.
The system stays out of the way until it has something useful to say.
Guardrails for error storms
Notifications solve the human side of alert fatigue. Ingest protection solves the server side. When one broken endpoint starts throwing nonstop, a self-hosted error tracker also needs to protect its queue, database, and disk.
Telebugs includes ingest protection for admins:
- Accepted errors per minute caps how much new work the instance accepts.
- Queue protection pauses intake when pending ingest jobs grow too quickly.
- Low disk protection pauses intake before storage pressure turns into a database problem.
- 429 responses are returned before Telebugs writes the ingest payload or enqueues more work when protection is active.
- Global warning banners make active protection states visible to admins.
That makes notification rules and low-resource error tracking work together: the team gets actionable alerts, and the self-hosted instance avoids accepting more than it can safely process. The release write-up has the detailed version: Guardrails for error storms.
When this approach makes sense
If your team is small to medium and values focus over exhaustive alerting, these controls are effective. You get the channels most teams actually use, including Slack, Discord, Teams, push, email, and webhooks, without adopting a full observability platform just to route production exceptions.
Larger organizations with dedicated SRE teams and complex escalation policies may still want dedicated incident tools or a broad monitoring platform. For most product teams shipping web and mobile apps, the combination of good grouping, flexible rules, multiple delivery channels, and server-side guardrails is the sweet spot.
Everything is included with your one-time Telebugs purchase. No per-user notification tiers or extra fees for webhooks.
How this compares to self-hosted Sentry
Self-hosted Sentry is part of a much larger monitoring platform. That can be the right fit for teams that want a broad observability stack, but it can be heavy when your main need is focused production error tracking.
Telebugs keeps notifications in the same lightweight product as grouping, reports, backtraces, breadcrumbs, releases, notes, retention, API access, MCP, and ingest protection. Setup is straightforward through the UI or API. The focus is on channels and rule types that solve alert fatigue for real product teams rather than trying to replicate every possible enterprise workflow.
You still get the Sentry SDK compatibility on the client side, so your existing instrumentation continues to work while the server-side experience becomes lighter and more targeted.
Frequently asked questions
What are error notification rules?
Error notification rules decide when an error alert should fire and where it should go. A good rule can alert on new issues, recurrences, spikes, every occurrence, or a frequency threshold while using cooldowns to avoid repeated noise.
Which notification channels does Telebugs support?
Telebugs supports email, PWA push notifications, Slack, Discord, Microsoft Teams, and custom webhooks. You can use different channels for different projects, environments, teams, or urgency levels.
Can I send the same error to multiple channels?
Yes. You can enable any combination of email, push, Slack, Discord, Teams, and webhooks for the same rule or project. Many teams use Slack for the room and push for the person on call.
How do I avoid alert fatigue on known issues?
Use muting and snoozing for temporary suppression, or create a rule that only fires on new errors or spikes. You can also use custom grouping or ignore patterns in the SDK for issues you never want to see again.
What is a notification cooldown?
A cooldown limits how often a rule can notify you about the same issue. It is useful during incidents because the first alert gets attention while repeated duplicate alerts are held back.
Do push notifications require the dashboard open?
No. The PWA can be installed on your phone or desktop and will deliver notifications even when the browser tab is closed (as long as the device has network access and notifications are allowed for the site).
Can I use webhooks for custom integrations?
Absolutely. Any service that accepts incoming webhooks (or a simple HTTP POST) can receive Telebugs notifications. You control the payload format and can include the full error details.
Can AI tools help triage error alerts?
Yes, if you connect an approved MCP client. Telebugs MCP support lets compatible AI tools inspect projects, error groups, reports, backtraces, breadcrumbs, notes, and release context from your self-hosted instance.
What happens during an error storm?
Notification rules and cooldowns reduce human noise. Ingest protection can also cap accepted errors per minute, protect the queue, pause intake when disk space is low, and return 429 responses before writing more ingest payloads.
Are there limits on how many notifications I can send?
There are no per-notification or per-event fees. Your only practical limits are the rate limits of the destination services (Slack, email providers, etc.) and your own infrastructure. Rules with cooldowns help you stay well within reasonable volumes.
Ready to get notified without the noise?
Read the Telebugs manual for notification details, review pricing, or request a private demo. When you are ready, buy Telebugs and set up the channels your team actually uses.