Zabbix alerts to Slack, Microsoft Teams and Mattermost

A chat message in Zabbix reaches a channel only because a chain of objects allows it. The trigger produces a problem event, the action decides which events qualify, the operation decides who is notified, the user's media entry decides which destination and filters apply, and the media type decides how the message is delivered. Each link can narrow the audience or widen it, so the reader should review the whole chain for every Slack, Microsoft Teams or Mattermost destination rather than checking only the media type.

A chat message is only as targeted as the user and media entries behind it. The media type holds the shared webhook logic and endpoint settings, but the per-user media entry supplies the values that make the message specific, such as a channel or recipient and a severity filter. If one user account is used as a shared alert destination, every action that targets that user will post into the same channel, which is how alert floods begin. Decide early whether each team gets its own user or media entry, and confirm which parameters the bundled Slack, Teams and Mattermost media types read in your version.

A webhook-based media type sends an HTTP request to the webhook URL configured for the destination. Zabbix builds the payload from a script in the media type, and macros such as the host name, trigger name, severity, event time and event ID are substituted into the message body before the request is sent. Test the output with names that contain quotes, backslashes or special characters, because unescaped values can produce malformed JSON that the chat service rejects. Confirm the exact script and the list of supported macros in your version's documentation before writing team-specific message templates.

Problem and recovery messages are separate operations, so each must be checked on its own. The action sends the problem message through its operations and the recovery message through its recovery operations, and both pass through the same user media and filters. A severity filter or a disabled recovery operation can allow the problem to reach the channel while the resolution never arrives, leaving people with an open alert that is already fixed. Test by triggering a controlled problem, resolving it, and confirming that both messages appear in the intended channel. Also confirm whether your media type links recovery messages to the original problem, since this affects how teams read the thread.

The most effective way to keep a shared channel usable is to decide, before any media type is configured, which team owns which problems. In Zabbix, host groups are the main routing key because they usually mirror ownership. Create one action per team with a condition on the host group, then add a second condition such as a service or environment tag where host groups alone are too coarse. Use the action's severity filter to control which levels reach the shared channel. Warnings can stay in the owning team's channel, while only high-severity problems appear in the shared one. Confirm in your Zabbix version how conditions combine across host groups, tags and severities before you rely on them.

Escalation is built from operation steps within an action, each with its own delay and its own recipients. A typical pattern, shown here as an illustrative example, sends the first step to the owning team's channel immediately and a second step to an on-call channel or a named user after a delay if the problem is still open and unacknowledged. Ask your Zabbix administrator to confirm how acknowledgment, recovery messages and step conditions behave in the version you run, because recovery messages must reach the same destinations as the original alert or teams will see problems that never close. Keep escalation targets few and named, so that a second step does not reproduce the flood it was meant to contain.

A single shared channel fills quickly during a storm because one fault produces many problems at once. A failed switch, hypervisor or upstream link can trigger dozens of dependent items across hosts, and each trigger creates its own problem and its own message. Reduce this at the source. Use trigger dependencies so that child triggers are suppressed while the parent problem is active, and avoid defining the same condition at several levels with separate triggers. Review whether event tags can group related problems under one service. Message volume is also limited by the chat platform's incoming webhook behavior, so check the rate limits in the Slack, Microsoft Teams or Mattermost documentation for your deployment instead of assuming them.

Test the routing on a sample of hosts before the full rollout. Pick one host group that has a known owner, create the team action and the escalation step for it, and run a controlled test such as a maintenance-period trigger or a deliberately failed test check. Measure how many messages reach the channel, confirm that each message lands in the right place, and verify that recovery notices arrive. Record who owns each action, who approves changes to conditions, and when the rules were last reviewed. Routing drifts as hosts and host groups are added, so schedule a review whenever a new team or host group appears, and treat an unexpected rise in channel volume as a signal to check the action conditions first.

Once you self-host Mattermost, the webhook target becomes a system your team operates, so its release lifecycle and availability belong in the alerting design. Mattermost runs as a single Linux binary backed by PostgreSQL, and it publishes server binaries on the 16th of each month. Each release line has its own support end date. For example, v11.11 was released on 2026-09-16 with support ending 2026-12-15, and v12.0 was released on 2026-10-16 with support ending 2027-01-15. Confirm which line your Mattermost server runs, record its end date, and schedule the upgrade ahead of it. A webhook that stops receiving security fixes can fail silently while Zabbix keeps reporting that the message was sent.

High availability is the decision that matters most if alerts must survive a chat outage. In Mattermost, clustering is available only on the Enterprise and Enterprise Advanced plans, and it depends on redundant application servers, redundant database servers and redundant load balancers. A cluster also needs shared file storage, such as Amazon S3, an S3-compatible service or a NAS mounted on every node. Local file system storage will not work correctly and risks corrupting files. Ask your Zabbix administrator to document what happens to an alert when the Mattermost endpoint is unreachable, including whether the media type retries, which channel receives the message next, and who is notified when delivery fails. That fallback path should be tested, not assumed.

Pricing is set by quote. Mattermost sells Professional, Enterprise and Enterprise Advanced as prepaid annual subscriptions based on seat licenses, and its pricing page lists no public prices and directs buyers to contact sales. The tier you need follows from your requirements. SSO and AD/LDAP user sync are included from Professional, high availability and FIPS 140-3 compliance from Enterprise, and air-gapped deployment in Enterprise Advanced. Request a written quote that states the seat count, the deployment model, whether HA is included, the support terms and the renewal terms. Ask the vendor whether integration or bot accounts consume seats. Infrastructure for PostgreSQL, shared storage and load balancing is a separate cost that your team or your implementation partner must budget for, and it recurs as long as the service runs.

Rocket.Chat is the alternative webhook target this topic covers, and the comparison depends on scale and plan. Its free Starter plan allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts. Its paid Commercial, Government and Defense plans are priced by quote, and air-gapped deployment is not available on Starter. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and its standard releases are supported for 6 months while LTS releases are supported for 12 months. Before choosing, confirm the user count that includes alert accounts, the plan that covers your HA design, and the support window of the version you will run.