How to Build a Customer Status Page from Zabbix Monitoring Data

The Gap Between What Zabbix Knows and What Your Customers See

Zabbix has thorough visibility into your infrastructure. You have host groups, trigger severities, problem states, and dashboards showing exactly which services are struggling. Your team knows the moment a database node drops or an application server stops responding.

Your customers know nothing until their support tickets start piling up.

The manual alternative — checking Zabbix, deciding it is worth posting about, logging into a status page tool, writing an update, and publishing it — takes minutes you often do not have during an active incident. By the time you post something, customers have already opened tickets, tweeted complaints, or assumed the worst.

This post walks through the automation chain that closes that gap: Zabbix fires a trigger, a webhook media type POSTs to Alert24's incoming webhook, and your public status page updates automatically. No manual steps, no alert fatigue, no delayed communication.

How the Automation Chain Works

Before building anything, it helps to understand what you are connecting:

1. A Zabbix trigger fires when a host crosses a threshold (database query time > 2s, service check FAILED, etc.)
2. Zabbix calls an action, which uses a media type to deliver a notification
3. The media type is a webhook that POSTs structured JSON to Alert24's incoming webhook endpoint
4. Alert24 receives the payload, maps it to the correct service on your status page, and updates the status automatically
5. When Zabbix resolves the trigger, a second webhook call marks the service operational again

The mapping between Zabbix host groups and Alert24 services is the key piece. A database host belongs to the "Database Servers" host group in Zabbix. You configure that group to map to the "Database" service in Alert24. When any host in that group has a problem trigger fire, the Database service goes degraded. When all problems in that group resolve, it returns to operational.

Creating the Webhook Media Type in Zabbix

In Zabbix, navigate to Administration > Media types and create a new media type with type Webhook.

The Parameters section is where you define the variables that get passed into your script. Add these:

Then paste this script into the Script field:

var params = JSON.parse(value);

var serviceId = params.alert24_service_id;
var isRecovery = params.event_value === '0';

var status;
if (isRecovery) {
    status = 'operational';
} else if (params.trigger_severity === 'Disaster' || params.trigger_severity === 'High') {
    status = 'major_outage';
} else if (params.trigger_severity === 'Average') {
    status = 'degraded_performance';
} else {
    status = 'partial_outage';
}

var payload = {
    service_id: serviceId,
    status: status,
    message: params.event_name
};

var req = new HttpRequest();
req.addHeader('Content-Type: application/json');

var response = req.post(
    params.alert24_webhook_url,
    JSON.stringify(payload)
);

if (req.getStatus() !== 200) {
    throw 'Alert24 webhook failed: ' + response;
}

return 'OK';

The severity-to-status mapping above is a starting point. Adjust it to match how your team thinks about customer impact — a "Warning" trigger on CPU might not warrant a degraded status page entry at all, in which case you add a check for that severity and return early.

Mapping Host Groups to Services with Host Macros

Rather than hard-coding a service ID in the media type, you use a Zabbix host-level macro so each host group can point to a different Alert24 service.

On each host (or on a host group template), add a user macro:

{$ALERT24_SERVICE_ID} = svc_abc123xyz

Replace svc_abc123xyz with the actual service ID from your Alert24 status page. You find this in Alert24 under Status Pages > your page > Services, where each service has a short ID in its settings.

This approach means your database hosts carry one macro value, your API hosts carry another, and your CDN hosts carry a third. A single media type and action handles all of them without any conditional logic in the webhook script.

Creating the Zabbix Action

With the media type configured, create a trigger action under Configuration > Actions > Trigger actions:

• Conditions: you can start with no conditions to catch everything, or filter to specific host groups or severities
• Operations: Send message to user group (your ops group), using the webhook media type you just created
• Recovery operations: Send recovery message using the same media type

The recovery operation is important. Without it, your status page will stay degraded forever after a trigger resolves. Make sure recovery is enabled and that it uses the same user group and media type.

Sending a Test Event

Before relying on this in production, verify it end to end. The fastest way is to use Zabbix's built-in media type test under Administration > Media types, click Test next to your webhook, and supply dummy parameter values with event_value set to 1 (problem) and then 0 (recovery).

Watch the Alert24 incoming webhook log — you will see the POST arrive, the service ID it resolved, and the status it applied. If the service ID does not match a known service, Alert24 will return an error explaining what went wrong.

You can also trigger this from the host side by deliberately putting a host into a problem state (temporarily lower a trigger threshold, for example) and watching the status page update in real time.

What This Looks Like in Practice

Once it is running, the workflow for your team changes. When a database host starts failing checks:

• Zabbix fires the trigger within the polling interval (typically 30–60 seconds)
• The webhook fires and marks "Database" as degraded on your public status page
• Customers visiting your status page see the update without you doing anything
• When the host recovers, Zabbix sends a recovery event and the service goes back to operational

Your team can still manually post incident updates through Alert24 for more detailed communication — explaining root cause, estimated resolution time, what you are doing — but the initial status change happens automatically. That is usually the most important part to get right.

Next Steps

Start with one host group and one service mapped together. Verify the full round trip — problem fires, status updates, recovery fires, status resets — before expanding to your full inventory.

From there, you can layer in additional Alert24 features: on-call routing so the right person gets paged when a trigger fires, incident timelines that capture what happened and when, and subscriber notifications so customers who opted in receive an email when a service goes degraded.

The Zabbix side of this is almost entirely configuration. The script above handles the severity mapping and HTTP call. The only judgment call is deciding which Zabbix severities warrant which Alert24 statuses for your specific services — and that is worth thinking through with your team before you go live.