All integrations

Integration

Checkmk alerts where people actually look

A notification plugin for Checkmk that delivers host and service alerts as messages to a chat or group. One bash script, no dependencies beyond curl — and it reports a failed delivery back to Checkmk instead of swallowing it.

Install

su - mysite
mkp add whatsapp_notify-2.0.0.mkp
mkp enable whatsapp_notify 2.0.0

Or upload the package under Setup → Maintenance → Extension packages. Works on Checkmk 2.x, Raw and Enterprise; the plugin only reads the standard NOTIFY_* variables.

Three steps to a working alert

01

Install and verify

Add the extension package, then prove it works before touching a rule. The script has a --test mode that sends one message from the site shell and prints the exact reason if the API refuses.

02

Clone your mail rule

Under Setup → Events → Notifications, clone the rule you already trust. Its contact selection and conditions carry over — you only swap the notification method, so nobody quietly stops getting paged.

03

Fill in three parameters

Choose Call with the following parameters and pass the instance ID, the destination chat ID and your API token. No callback URL to register and no approval process to wait on.

Verify before you wire it up

~/local/share/check_mk/notifications/check_mk_whatsapp-notify.sh \
    --test 123 4915112345678@c.us YOUR_API_TOKEN

What lands in the chat

Host name and alias first, so a group alert is attributable at a glance. Then the state transition, the check output, the addresses and the site name — enough to triage from a phone without opening the GUI.

Acknowledgements and custom notifications carry the operator's comment, so the group sees who took it and why.

srv01 (Web frontend, production)

❌ SERVICE PROBLEM

Filesystem /var
State changed from OK to CRIT
CRIT - 95.2% used (47.6 of 50.0 GB)

IPv4: 10.0.0.5

2026-09-04 16:04 | mysite

A notification that fails silently is worse than none

The obvious way to do this is a curl call in a two-line script. The problem is what happens when it does not work: curl exits 0 on an HTTP 401, and the API answers 200 with an error body when the connected account has dropped off. A naive script reports both to Checkmk as delivered. You find out during the next outage.

Failures reach Checkmk

Every failure path exits non-zero with a specific reason, so Checkmk retries it and records it. notify.log tells you whether the token was rejected, the instance was wrong, or the account needs reconnecting.

Check output cannot break the request

Service output routinely contains quotes, backslashes and newlines — a Windows path or a multi-line plugin result is enough. Every value is JSON-escaped, so the alert that trips on the ugliest output still goes out.

What you see in notify.log What to fix
is not a valid chat ID The suffix is missing. See the table below.
rejected the API token (HTTP 401) Token wrong, expired, or missing scopes.
instance <n> not found (HTTP 404) Wrong instance ID, or it belongs to another account.
did not send the message The account is disconnected — reconnect it in the dashboard.
curl failed with exit code 28 The site cannot reach the API. Check egress firewall or proxy.

The chat ID is the one thing to get right

Parameter 2 decides where the alert lands. Most teams point it at a group so the whole on-call rotation sees the same message. The plugin rejects a malformed ID at startup rather than sending into the void.

Target Format
One person 4915112345678@c.us
On-call group 123456789-123456789@g.us
Channel 123456789@newsletter

Checkmk questions

What the plugin does and where its limits are.

Checkmk 2.x, Raw and Enterprise, and it still works on 1.6. The plugin only reads the standard NOTIFY_* environment variables that Checkmk has exposed to notification scripts for many releases, so new versions are expected to work unchanged.

Either. The MKP is one command and survives site updates cleanly. If you prefer, download the single script into ~/local/share/check_mk/notifications/ and make it executable — it has no dependencies beyond bash and curl.

Yes. Leave parameter 3 empty and set WAAPI_API_TOKEN in the site environment instead. The script falls back to it, so the token never appears in the rule configuration or in a WATO export.

The script exits non-zero with a specific reason, which Checkmk logs and retries. That is the deliberate difference from a hand-rolled curl call: curl exits 0 on an HTTP 401, and the API answers 200 with an error body when the account is disconnected, so a naive script reports both as delivered.

No. Billing is a flat rate per connected account. A noisy night costs the same as a quiet one, which is the point — per-message pricing makes people tune alerts for the invoice rather than for the on-call rotation.

Yes. Create one notification rule per destination, each with its own chat ID in parameter 2. Checkmk decides which rule matches; the plugin just delivers what it is handed.

Yes, BSD 3-Clause, on GitHub. It began as an adaptation of the Checkmk Telegram notification script by Benedikt Filip, which the source and README credit.

Connect an account and start sending

One flat rate per connected account. Unlimited messages, no approval process, no per-message invoice.