Product
Alerts through your own Telegram, Slack, email or webhook
Belvador sends alerts for new issues, regressions and spikes, for failing monitors, uptime incidents and SLO burn. Each workspace connects its own senders, so messages come from your bot or your mailbox and your provider's limits apply.
What an alert looks like
Three sample alerts in Telegram, built by the same code that sends real ones. The workspace, projects and error are invented.
Belvador
Sample alert
Open issue[Belvador] New error · CHECKOUT-API-1F · production
TypeError: Cannot read properties of undefined (reading 'total')
at POST /api/checkout
checkout-api · error · release 2026.10.24
Belvador
Sample alert
Open monitor🔴 Monitor missed — Nightly invoices (production)
No check-in arrived before the deadline.
billing · missed
At 2026-10-24 02:35 (Europe/Berlin) · 2026-10-24 00:35 UTC
Schedule: At 02:30
Last healthy run: 2026-10-23 00:31 UTC
Belvador
Sample alert
Open uptime check🔴 Down — Storefront home (production)
Storefront home is failing from Europe, North America.
storefront
Target: https[:]//shop.example.com/
Reason: timed out
Down since 2026-10-24 02:47 UTC
The short answer#
Alert on new issues, regressions, escalating issues, failing monitors, uptime incidents and SLO burn.
Send through your own Telegram bot, Slack webhook, SMTP or Resend account, or a signed webhook.
Monitors and checks send one message when they break and one when they recover.
No on-call schedules or phone alerts; forward a webhook to the on-call tool you use.
Where alerts can go#
| Destination | You connect |
|---|---|
| Telegram | Your own bot from @BotFather; Belvador finds the private chat, group or channel |
| Slack | An incoming webhook for one channel |
| An SMTP account or a Resend API key, with your From address | |
| Webhook | Any HTTPS endpoint; alerts arrive as signed JSON in the Standard Webhooks format |
Belvador sends a test message before it saves a destination, and stores credentials encrypted for sending only. There is no shared Belvador sender (alerts guide).
What can trigger an alert#
| Alert on | When |
|---|---|
| Errors | A new issue, a regression (a resolved issue came back) or an escalating issue |
| Connection problems | A project's SDK connection breaks — a revoked key still in use, errors from a blocked origin |
| Monitor incidents | A cron or ping-URL monitor misses, fails, runs too long or needs review (cron monitoring) |
| Uptime checks | Most regions see a check fail; certificate expiry warnings (uptime monitoring) |
| SLOs | An error budget burns too fast (page) or too slowly to ignore (ticket) (burn-rate alerts) |
Keeping noise down#
Each rule has a minimum level, environments and a Don't repeat for window, so the same issue does not alert twice inside it.
Monitors and uptime checks send one message when they start failing and one when they recover. Changing from one failure to another does not send a second message.
A muted monitor, check or SLO keeps recording and sends nothing.
An SLO with too little data sends nothing rather than a guess.
What messages contain#
Names, codes, times and a link to the dashboard. Error alerts carry the issue title; monitor, uptime and SLO messages never contain error messages, response bodies, keys or user ids. Webhook payloads and signature checks are documented in custom webhooks.
Limits#
No on-call schedules, escalation policies or phone and SMS alerts. Send a webhook to the on-call tool you use.
Delivery depends on your provider: a revoked bot token or a changed mail password turns the destination Failing until you update it.
Questions#
Can I send different projects to different channels?#
Yes. Each destination lists the projects it may receive, and each rule picks projects and destinations.
How fast does an alert arrive?#
Error alerts are sent when the node groups the event into a new or regressed issue. Monitor and uptime alerts follow the schedule, grace period and round rules shown when you create them.
Posts on this topic
All posts- A prompt to add error tracking to a Lovable app, and how to check itThe prompt to add error tracking to a Lovable app: which files, in which order, what to keep, and how to prove it works. Old order 0 of 12, fixed 12 of 12.
- How to trace failed agent tool calls without losing or doubling errorsSpan status, exception events and error reporting for agent tool calls that fail or retry, with counts from 60 agent runs and one fix for the handler.
- SLO burn-rate alerts explained with four outagesFour synthetic incidents replayed through a real SLO evaluator: when burn-rate alerts open and close, and why a 5-minute threshold paged 16 times.
- No MCP server: three ways to hand Belvador errors to your agentBelvador has no MCP server. Three ways to work with coding agents anyway: paste issue evidence, Markdown docs and llms.txt, and Standard Webhooks alerts.
Try it on your own Hetzner project
Free during the beta. Hetzner bills the server; Belvador never bills per event.