Sản phẩm
Cảnh báo qua Telegram, Slack, email hoặc webhook của chính bạn
Belvador gửi cảnh báo khi có issue mới, lỗi quay lại và lỗi tăng vọt, khi monitor lỗi, uptime sập và SLO cháy ngân sách. Mỗi workspace tự kết nối kênh gửi, nên tin đến từ bot hoặc hộp thư của bạn và tuân theo giới hạn của nhà cung cấp bạn dùng.
Một tin cảnh báo trông thế nào
Ba tin cảnh báo mẫu trên Telegram, tạo bằng chính đoạn code gửi tin thật. Workspace, project và lỗi đều là dữ liệu mẫu.
Belvador
Tin cảnh báo mẫu
Mở issue[Belvador] Lỗi mới · CHECKOUT-API-1F · production
TypeError: Cannot read properties of undefined (reading 'total')
tại POST /api/checkout
checkout-api · error · release 2026.10.24
Belvador
Tin cảnh báo mẫu
Mở monitor🔴 Monitor trễ — Nightly invoices (production)
Không có check-in nào tới trước hạn.
billing · trễ
Lúc 2026-10-24 02:35 (Europe/Berlin) · 2026-10-24 00:35 UTC
Lịch: Vào 02:30
Lượt khoẻ gần nhất: 2026-10-23 00:31 UTC
Belvador
Tin cảnh báo mẫu
Mở kiểm tra uptime🔴 Không truy cập được — Storefront home (production)
Storefront home đang lỗi từ Châu Âu, Bắc Mỹ.
storefront
Địa chỉ: https[:]//shop.example.com/
Lý do: quá thời gian chờ
Lỗi từ 2026-10-24 02:47 UTC
Trả lời nhanh#
Cảnh báo khi có issue mới, lỗi quay lại, issue tăng vọt, monitor lỗi, uptime sập và SLO cháy ngân sách.
Gửi qua bot Telegram, Slack webhook, tài khoản SMTP hoặc Resend, hay webhook có chữ ký của chính bạn.
Monitor và check gửi một tin khi hỏng và một tin khi hồi phục.
Không có lịch trực hay gọi điện; chuyển webhook sang công cụ on-call bạn đang dùng.
Cảnh báo gửi tới đâu#
| Kênh | Bạn kết nối |
|---|---|
| Telegram | Bot riêng tạo từ @BotFather; Belvador tìm chat riêng, nhóm hoặc kênh |
| Slack | Một incoming webhook cho một kênh |
| Tài khoản SMTP hoặc API key Resend, với địa chỉ gửi của bạn | |
| Webhook | Bất kỳ endpoint HTTPS nào; cảnh báo tới dưới dạng JSON có chữ ký theo chuẩn Standard Webhooks |
Belvador gửi tin thử trước khi lưu kênh, và lưu thông tin đăng nhập đã mã hoá, chỉ dùng để gửi. Belvador không có kênh gửi dùng chung (hướng dẫn cảnh báo).
Điều gì kích hoạt cảnh báo#
| Cảnh báo theo | Khi nào |
|---|---|
| Lỗi | Issue mới, lỗi quay lại (issue đã resolve xuất hiện lại) hoặc issue tăng vọt |
| Sự cố kết nối | Kết nối SDK của project hỏng — khoá đã thu hồi vẫn được dùng, lỗi từ origin bị chặn |
| Sự cố monitor | Monitor cron hoặc ping URL bị lỡ, lỗi, chạy quá lâu hoặc cần xem lại (theo dõi cron) |
| Uptime check | Đa số vùng thấy check lỗi; cảnh báo chứng chỉ sắp hết hạn (theo dõi uptime) |
| SLO | Ngân sách lỗi cháy quá nhanh (gọi ngay) hoặc cháy chậm nhưng không thể bỏ qua (ticket) (cảnh báo tốc độ cháy) |
Giảm nhiễu#
Mỗi quy tắc có mức tối thiểu, môi trường và khoảng Không lặp lại trong, nên cùng một issue không cảnh báo hai lần trong khoảng đó.
Monitor và uptime check gửi một tin khi bắt đầu lỗi và một tin khi hồi phục. Chuyển từ kiểu lỗi này sang kiểu khác không gửi thêm tin.
Monitor, check hay SLO đã tắt tiếng vẫn ghi nhận nhưng không gửi gì.
SLO thiếu dữ liệu không gửi gì, thay vì đoán.
Tin cảnh báo chứa gì#
Tên, mã, thời gian và link tới dashboard. Cảnh báo lỗi có tiêu đề issue; tin của monitor, uptime và SLO không bao giờ chứa thông điệp lỗi, nội dung response, khoá hay id người dùng. Payload webhook và cách kiểm chữ ký có ở webhook tuỳ chỉnh.
Giới hạn#
Không có lịch trực, chính sách leo thang hay cảnh báo qua điện thoại và SMS. Gửi webhook tới công cụ on-call bạn đang dùng.
Việc gửi phụ thuộc nhà cung cấp của bạn: bot token bị thu hồi hay mật khẩu email đổi sẽ chuyển kênh sang Failing cho tới khi bạn cập nhật.
Câu hỏi thường gặp#
Gửi project khác nhau tới kênh khác nhau được không?#
Được. Mỗi kênh liệt kê các project được phép nhận, và mỗi quy tắc chọn project và kênh.
Cảnh báo tới nhanh cỡ nào?#
Cảnh báo lỗi được gửi khi node gộp event thành issue mới hoặc issue quay lại. Cảnh báo monitor và uptime theo lịch, thời gian ân hạn và quy tắc vòng kiểm hiện lúc bạn tạo chúng.
Bài viết về chủ đề này
Tất cả bài viết- Observability cho team nhỏ: năm tín hiệu, theo đúng thứ tự cần dùngTeam nhỏ nên theo dõi gì trước: lỗi, job định kỳ, uptime từ bên ngoài, một SLO, rồi mới tới trace. Dựa trên bốn thí nghiệm, kèm chỗ mỗi tín hiệu bỏ sót.
- Burn rate trong SLO, giải thích dễ hiểu qua bốn sự cốBurn rate SLO giải thích bằng bốn sự cố giả lập chạy qua bộ đánh giá thật: cảnh báo đa cửa sổ mở, đóng lúc nào, và vì sao ngưỡng 5 phút kêu tới 16 lần.
- Prompt cài theo dõi lỗi cho app Lovable, và cách kiểm tra nó chạyPrompt cài theo dõi lỗi cho app Lovable: sửa file nào, theo thứ tự nào, giữ lại gì, chứng minh nó chạy ra sao. Thứ tự cũ báo 0/12 lỗi, bản sửa 12/12.
- Belvador không có MCP server: ba cách đưa lỗi cho agentBelvador không có MCP server. Ba cách làm việc với coding agent: dán bằng chứng của issue, tài liệu Markdown và llms.txt, cảnh báo qua Standard Webhooks.
Thử trên project Hetzner của bạn
Miễn phí trong giai đoạn beta. Hetzner tính tiền máy; Belvador không bao giờ tính tiền theo event.