Chat & alerts channels

Chat & Alerts (/connect/channels, in the Advanced → Integrations hub) is the single, central store for the channels MZPanel delivers notifications to. Connect a chat app once here, add one or more destinations to it, and every other feature — alert rules, uptime monitoring and server health alerts — can send to it. It’s an account-level page (it spans your whole organization) and is available on all plans.

Connect a channel, step by step

1. Click Connect channel (top right), or Connect on any card in the Add a channel catalog to preselect that app.
2. In the drawer, pick the App — Email, Telegram, Slack, Discord, Microsoft Teams, Generic webhook or Google Chat.
3. Give the connection a Label (e.g. “Ops Telegram”). If you leave it blank it defaults to the app name.
4. For Telegram only, paste the Token / key — a bot token from @BotFather. The other apps don’t need a connection token; their secret is the destination value itself.
5. Fill the destination value for the app: an email address, a Telegram chat ID, or an incoming-webhook URL (Slack / Discord / Teams / Google Chat / generic). Optionally name the destination.
6. Click Connect & test. MZPanel saves the connection and sends a real test message to that first destination. If the test lands, the connection shows Connected; if it fails you get an inline warning so you can fix the value and retry from the list.

What else you can do

Each connected app is a card listing its label, the app name, a masked secret hint, its destinations, and when it was last used.

• Add a destination — a connection can fan out to many targets. Use Add <recipient / chat / channel / space / endpoint> on a card to add another email, chat or webhook to the same app.
• Send test — the circular-arrow button re-sends a test message. Hover a single destination for its own Send test, or use the card-level test to hit the first one.
• Edit a destination — rename it, and optionally replace its target value (leave the value blank to keep the existing one — you never see the stored secret).
• Remove a destination — the ✕ on a destination deletes just that target.
• Revoke — the trash icon (with a confirm step) removes the whole connection and all its destinations.

Once you’ve connected channels, decide which events reach them over in Notification rules — this page only manages the connections, not what gets sent.

How it works

The page is backed by the account-scoped /v1/notify API. The data model is Connection → Destinations:

• A Connection is one connected app. Only Telegram carries a connection-level secret (the bot token); for every other app the secret lives per-destination (the webhook URL or email address).
• A Destination is a single delivery target under a connection — a chat ID, a channel webhook, a space, or an email recipient.

Action	API route
List connections + destinations	GET /v1/notify/connections
Connect an app	POST /v1/notify/connections
Rename / re-key a connection	PATCH /v1/notify/connections/:id
Revoke a connection	DELETE /v1/notify/connections/:id
Add a destination	POST /v1/notify/connections/:id/destinations
Rename / retarget a destination	PATCH /v1/notify/destinations/:did
Remove a destination	DELETE /v1/notify/destinations/:did
Send a test message	POST /v1/notify/destinations/:did/test

Tokens and webhook URLs are encrypted at rest with the control plane’s secret box — the API only ever returns a masked ••••last4 hint, never the secret. The control plane decrypts a value only at the moment it delivers.

Delivery is one shared primitive used by tests and by real event fan-out, so a successful Send test proves the whole chain end to end. Per app it does:

• Telegram — Bot API sendMessage with your token and chat ID.
• Slack / Microsoft Teams / Google Chat — POST {"text": …} to the incoming webhook.
• Discord — POST {"content": …} to the webhook.
• Generic webhook — POST {subject, body, text} JSON to your endpoint.
• Email — relayed through the control plane’s mail relay (see the caveat below).

Because delivery happens entirely on the control plane, there’s nothing to install on any server. Alert rules and uptime monitors reference these same destinations, so connecting a channel here immediately makes it available everywhere.

API & automation

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

Gotchas & troubleshooting

The value is write-once — you can’t read it back

After you save, only the last 4 characters of a token or webhook URL stay visible. There’s no way to reveal the full secret again. To change it, edit the destination (or re-key the connection) with a fresh value — leaving the field blank keeps the current one.

• Telegram needs a bot token and a chat ID. The token goes in the connection’s Token / key; the destination value is the chat ID (e.g. -1001234567 for a group, or your own user ID). Add the bot to the chat/group first, or it can’t post.
• Microsoft Teams uses the new Workflows webhook. Office 365 Connectors are retired — create the webhook via Workflows (Power Automate), not the old connector, or delivery will fail. The connect drawer shows this note inline.
• A failed test marks the connection Failed. The status reflects the last delivery attempt. Fix the token/URL and hit Send test again; a success flips it back to Connected.
• Email delivery depends on a configured relay. Chat channels (Telegram/Slack/Discord/Teams/Google Chat/webhook) deliver out of the box. Email saves and passes the connect step, but a message only actually goes out when the control plane has an email relay configured — otherwise the email channel is inert (saved but skipped). Prefer a chat/webhook channel if you need guaranteed delivery today.
• The “ChatOps” badge is future, not live. Telegram and Slack show a small ChatOps tag hinting at two-way control (approving actions from chat). That’s a roadmap marker — today these channels are outbound-only (MZPanel sends, it doesn’t receive commands).
• Connecting a channel doesn’t send anything by itself. Nothing is delivered until an alert rule or an uptime monitor is pointed at the destination. Connect here, route there.
• Channels are org-wide. They belong to the organization, so every member with Integrations access sees and can use the same connections.

Related

• Notifications & alerts — route fleet events to these channels.
• Uptime monitoring — send up/down alerts to a connected destination.
• API reference — manage connections programmatically (Max plan).