An SMS gateway exists because everything else can fail. Email needs a working uplink, Slack needs a working uplink, your ticketing system needs a working uplink, and all three of them are behind the same switch as the monitoring server that is trying to tell you the switch is on fire. A gateway with a SIM card in it does not care. Which raises the obvious question nobody asks until the wrong night: who is watching the gateway?
This is how to point Zabbix at an SMSEagle and collect the device's own health - modem registration, signal strength, queue depth, temperature - using the free template initMAX publish. It takes about ten minutes and the fiddly part is not the Zabbix side, it is scoping the API token.
Everything in a normal notification path shares a dependency: the network. Not the internet in the abstract - your uplink, your router, your DNS. When the outage is upstream of all of that, a monitoring system in perfect health sits there generating alerts it cannot deliver, which is arguably a worse failure than not noticing at all, because the dashboards look busy.
A hardware gateway breaks the dependency by carrying its own path out: a SIM, a modem, an antenna. Devices with two modems run them in failover, so a dead SIM, an exhausted prepaid balance or a failed modem still leaves a route. For anyone in scope for GDPR or NIS2 there is a second argument that has nothing to do with reliability: the message goes straight from your network to the carrier, so alert contents - which routinely name hosts, services and failure modes - never pass through a third-party SaaS.
A detail worth knowing before you plan rack space. These units run on PoE. In a datacentre that is a shrug; on a crowded rack or a home lab where every socket is already spoken for, it is the difference between installing it today and ordering another PDU.
In the SMSEagle web UI open Users, create a user for the integration and click Access to API. Select APIv2, generate a token, and copy it now - the UI will not show it to you again.
Then scope it under Manage allowed API methods. The permission list is granular, which is a gift rather than a chore: this token only ever reads, so nothing in it should be able to send a message. Enable the read methods the template polls - message counts, full modem information, and the device status group covering service states like SNMP and MQTT. Leave every send and every write method off.
Do not reuse this token for the media type. If you later set the
gateway up to send Zabbix alerts, that needs
Messages → Send SMS, and it is tempting to widen this token and
use one everywhere. Keep them separate. A read-only monitoring token that leaks
from a Zabbix macro cannot be used to send messages on your account.
The template lives in initMAX's public repository. Download
template_smseagle_http_7.0.yaml -
note the default branch is production/free, not main, which
is the usual reason a hand-typed raw URL 404s.
In Zabbix go to Data collection → Templates → Import,
choose the file and import. It lands in the template group
Templates/initMAX as SMSEagle by HTTP.
Create a host under Data collection → Hosts, give it a host group, and link SMSEagle by HTTP. It needs no interface - HTTP agent items carry their own URL, built from the macros below.
| Macro | What it is | Needed |
|---|---|---|
{$HOST.API.SMSEAGLE} | IP address or hostname of the device API | Yes |
{$TOKEN.API.SMSEAGLE} | The APIv2 token from step 1 | Yes |
{$SCHEMA.API.SMSEAGLE} | Connection scheme, http or https | Set it |
{$SMSE.MIN.SIGNAL.STRENGTH} | Minimum acceptable signal strength, 0-100 | Tune |
{$SMSEAGLE.ERROR.THRESHOLD} | Message error count increase that raises an alert | Tune |
{$SMSEAGLE.TEMP.HIGH} | High temperature threshold in Celsius | Tune |
{$SMSEAGLE.NODATA.TIMEOUT} | No-data timeout; must exceed the 1h unchanged-value heartbeat | Leave |
Macro names and descriptions read from the published template, so they match what you will import.
Two of those deserve a note. {$SCHEMA.API.SMSEAGLE} is the one people
miss, because it has a default and the host looks configured without it - set it
deliberately to match how the device actually answers, or you will spend twenty
minutes on a working device that returns nothing. And
{$SMSEAGLE.NODATA.TIMEOUT} has to stay longer than the template's
one-hour unchanged-value heartbeat, or you will manufacture no-data alerts on a
gateway that is simply idle. An idle SMS gateway is the normal state. That is the
whole point of it.
Thirty-one items and one discovery rule. Rather than list all of them, here is what they are actually for, because the useful split is not by protocol but by which failure each one catches.
| Group | Catches |
|---|---|
| Modem discovery (LLD) | Per modem: IMEI, IMSI, network name, number, signal strength. On a dual-modem unit you get two of each automatically, which is the only way to notice that failover has quietly been running on one modem for a month. |
| Signal strength | The slow failure. Signal degrades over weeks as something changes in the building; it does not page anyone until it crosses the threshold you set in {$SMSE.MIN.SIGNAL.STRENGTH}. |
| Message counters | Inbox, outgoing, delivered, queued, errors. A rising queue means messages are being accepted and not sent, which looks healthy from the Zabbix side right up until nobody gets paged. |
| Device and service status | Network registration and service states. Registration is the one that matters: a modem can be powered, healthy and simply not registered to a network. |
| Environment | Device temperature and humidity from the onboard sensors. With the optional external sensors this doubles as rack environmental monitoring. |
It is worth being precise about what monitoring the gateway buys you, because it is not obvious. The gateway is your notification path of last resort. If it fails silently, nothing tells you - by definition, the thing that would have told you is the thing that broke. You find out during the next real incident, which is the worst possible time to discover that the SIM expired in March.
So the alerts worth wiring up first are the boring ones: modem not registered, signal below threshold, outbound queue not draining, error count climbing. None of those are exciting and all of them are the difference between an alerting path that works and one you merely believe works.
Test the path, not just the device. Monitoring tells you the gateway is healthy. It does not tell you that a Zabbix action is wired to it correctly, that the recipient list is current, or that the person on call changed jobs. Send a real test message on a schedule - monthly is plenty - and have a human confirm receipt.
SMSEagle run a hosted demo instance: fill in a short form and they set up access to a live device UI within a few minutes. It is enough to see the API, generate a token and confirm the template imports cleanly before anything arrives on a purchase order. Worth doing in the order given here - token first, template second - because that is where the time actually goes.
Eleven minutes: what is in the box, why a hardware gateway exists at all, and the template import and macro setup end to end.
Two numbers changed since the video. It reports 23 items and two
discovery rules. The template as published today ships 31 items and one
discovery rule - modem discovery, with temperature now handled by ordinary
items rather than its own LLD. It also gained the
{$SCHEMA.API.SMSEAGLE} macro, which the video never sets because it
did not exist yet. The figures on this page are the current ones.
Out-of-band notification is one of those things nobody budgets for until the night it was needed and was not there. If you are working out whether a hardware gateway is justified for your environment, or how to fit one into an existing Zabbix estate, tell me what you run and what your escalation path looks like now.