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
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.
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.
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.