Getting woken by an alert is only half a workflow. The other half is telling everyone else that you are awake and looking at it - otherwise the second and third engineer on the escalation get paged for a problem that is already being handled, and the problem view fills up with alerts nobody has claimed.
Acknowledging normally means opening a laptop, reaching the Zabbix frontend, finding the problem and clicking. At three in the morning, over a phone tether, that is a lot of friction for what is really a one-word answer. This is how to make the reply to the alert SMS do it instead.
The firmware floor is not optional and fails quietly. 6.31 added
the native POST (Zabbix ACK) webhook method. On older firmware the
outgoing half still works perfectly - the alert arrives, it even contains the
acknowledgement instructions - and the reply is simply never processed. Nothing
errors. People text back, believe they have acknowledged, and the problem sits
unacknowledged in Zabbix. Check the firmware version before you trust this.
The part that makes this practical is that the inbound leg is handled by the gateway itself. There is no listener to write, no service to host, nothing new exposed to the internet. The gateway receives the SMS and posts to the Zabbix API directly.
In Zabbix go to Users → API tokens → Create API token. Name it for the integration, assign it to a user that is allowed to acknowledge problems, set an expiry, and copy the value.
The user choice matters more than it looks: every acknowledgement made this
way is recorded against that user. Point it at your admin account and the
audit trail says "Admin" for every ack regardless of who actually replied. Create a
service user with a name that reads sensibly in the problem view - something like
sms-ack - so the event log is honest about how the acknowledgement
arrived.
Set an expiry you will actually notice. A token with no expiry is convenient until it is the credential nobody rotated for four years. A token with a short expiry silently stops your acknowledgement path on a random Tuesday. Pick a date, and put the renewal somewhere that pages a human.
In the SMSEagle UI open Webhooks and add a rule:
| Field | Value |
|---|---|
| URL method | POST (Zabbix ACK) - the native method added in 6.31 |
| URL | Full path to your Zabbix API endpoint, ending in api_jsonrpc.php |
| API key of your service | The Zabbix API token from step 1 |
| Send request when | Always send |
| Send request for | Incoming message |
Field values from the initMAX media type README.
Mind the sub-path. The URL is the API endpoint, not the frontend
URL. If Zabbix is served at the web root it is
https://zabbix.example.com/api_jsonrpc.php; if it runs under a
/zabbix sub-path - which is the default for several distribution
packages - it is
https://zabbix.example.com/zabbix/api_jsonrpc.php. Getting this
wrong produces a webhook that fires and a problem that never gets acknowledged.
With the media type in place, the problem message already carries its own instructions. The relevant line reads:
For ACK please respond with message: ACK {EVENT.ID} <message>So an alert carrying event ID 26 is acknowledged by texting back:
ACK 26 on it, looking nowThe event ID is mandatory - it is what ties the reply to one specific problem, and it is why the outbound message has to include it. The trailing message is optional and lands in Zabbix as the acknowledgement text, so it is worth using: "on it" and "known, ignoring until Monday" mean very different things to the next person who looks at the problem view.
Within a few seconds the problem shows as acknowledged in Zabbix, attributed to the token's user, with your text attached.
It would be friendlier to reply "ack" and have the system work out which problem you meant. It would also be wrong. An engineer on call during a bad night has several unresolved alerts on their phone, arriving out of order and interleaved with everything else. Any scheme that infers the target - most recent, only open one - acknowledges the wrong problem exactly when the cost of doing so is highest.
Requiring the ID makes the reply unambiguous and auditable at the cost of typing two digits. That is the right trade, and it is worth understanding rather than working around, because the temptation to "simplify" it later is real.
Acknowledgement is not resolution. The problem stays open in Zabbix and the trigger still governs when it clears - all this changes is that the problem is marked as claimed, with a name and a note against it. If your escalation actions are configured to stop paging on acknowledgement, that now works from a phone. If they are not, this changes nothing about who gets woken next, and that is worth checking before you rely on it.
Seven minutes, ending with a real reply from a phone showing up as an acknowledgement in the Zabbix problem view.
Acknowledgement only means something if the workflow behind it does - who is expected to ack, how fast, and what escalates when nobody does. If your problem view is a wall of unacknowledged alerts that everyone has learned to scroll past, the fix is usually process rather than product.