Notifications & alerts

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

Notifications is where you see what’s happening across your fleet and decide where it gets sent. It’s a drawer you open from the topbar bell — click the bell for a quick preview of recent items, or View all notifications to open the full drawer. (The old /notifications page is gone; that URL now just opens this drawer.) It has two tabs: a Feed (your real in-app stream of recent events) and Rules (which events go to which chat/email channels). It’s account-level — it spans every server in your organization — and it’s available on all plans.

Route an event to a channel, step by step

Rules are the real engine of this page: when a fleet event fires (a backup fails, a server goes down, a certificate is expiring), a matching rule delivers it to your connected channels.

First connect at least one channel — Telegram, Slack, Discord, email, a webhook, and so on — in Chat & Alerts. The Rules tab can only route to destinations that are already connected there.
Open the Notifications drawer from the bell, switch to the Rules tab and click New rule to open the rule drawer.
Give the rule a Name (e.g. “Critical incidents”).
Pick the Events to match — Backup failed, Server down, SSL expiring, Deploy finished, Security alert, and more. Select as many as you like.
Set the Minimum severity — Info, Warning or Critical. The rule only fires for events at or above this level.
Under Send to, tick the destinations that should receive it. Only currently connected destinations appear here.
Click Save rule. The rule shows up as a card with its severity badge, matched events, and destination chips, and starts routing immediately.

What else you can do

Feed tab — scroll your real in-app stream of recent notifications, Mark all as read, Clear all, or click an item to mark it read and jump to the related server or backup. Unread items also drive the bell’s badge count.
Enable / disable a rule — flip the toggle on any rule card to pause routing without deleting the rule.
Edit a rule — the pencil reopens the drawer to change events, severity or destinations.
Delete a rule — the trash icon removes it.
Jump to Chat & Alerts — the Connect one → hint and the header link take you straight to Chat & Alerts to add channels.

Destination chips dim when their channel is disconnected, so a broken route is easy to spot on the card.

How it works

Both tabs are fully live and org-scoped. Rules are stored on the control plane and served by the /v1/notify API (GET/POST/PATCH/DELETE /v1/notify/rules); the Feed is a real in-app inbox served by /v1/notifications (list, unread count, mark-read, mark-all, clear). Channel credentials live separately as connections + destinations under the same API, encrypted at rest — the API only ever returns a masked last-4 hint, never the secret.

When something happens in your fleet, the originating operation emits a notify event (kind, severity, optional server, title, body). A dispatcher matches it against your enabled rules:

the event kind must be in the rule’s events,
its severity must be at or above the rule’s minimum,
the server must be in the rule’s scope,

On a match it always writes a row to your in-app Feed, then resolves each matching rule’s destinations and delivers through the shared delivery primitive (the same one Test uses). So a rule with no external channels still records everything to the Feed — external delivery is additive. To keep things quiet it applies quiet hours and a per-event cooldown dedup window, so a flapping condition can’t spam you. Quiet hours mute only external delivery; the Feed still records the event. Critical events bypass quiet hours.

Events are emitted from the operations that produce them — backup runs (done/failed), the agent WebSocket (server up/down), the SSL/domain expiry scanner, the resource “noisy neighbor” watcher (resource cap), deploys, and the agent security-update evaluator. There’s nothing to install on the box: delivery happens entirely on the control plane.

API & automation

This is a control-plane page, not a single box, so the on-box mz CLI doesn’t apply. Rules and channels are managed through the account API under /v1/notify (rules, connections, destinations, and a per-destination test send). Programmatic API access is a Max-plan feature — see the API reference.

Gotchas & troubleshooting

Rules deliver to the Feed even with no channel. A rule with no destinations still records matches to your in-app Feed; connecting a channel in Chat & Alerts adds external delivery on top.
A rule needs a name and at least one event before Save enables. A destination is optional (Feed-only rules are valid).
Every event in the picker has a producer. The rule drawer only lists events that something actually emits today — backup failed/completed, server down/back up, SSL/domain expiring, deploy finished, security alert, and resource cap.
Email needs a relay to actually send. Email destinations save and pass the connect step, but no message is delivered unless the control plane has an email relay configured; chat channels (Telegram/Slack/Discord/Teams/Google Chat/webhook) deliver out of the box.
Uptime & per-server legacy alerts deliver to channels but not the Feed. Older uptime and per-server alert routes still fire to their channels directly; they don’t yet write in-app Feed rows, so those specific alerts won’t appear in the bell.
Quiet hours don’t silence Critical. By design, critical events are delivered even inside a rule’s quiet window.
Repeated alerts are de-duplicated. A cooldown window suppresses the same event/server key if it fires again quickly, so you may see one message where the condition flapped several times.
A dimmed destination chip means its channel is disconnected. Reconnect or re-test it in Chat & Alerts.

Chat & Alerts — connect the channels rules send to.
Backups — a common source of the events you’ll route.