For a truly unmanned site, a text message is often the most reliable way to reach a human, because a phone buzzing in a pocket at 3 a.m. gets noticed when an email sitting in an inbox does not. Setting up SMS alerts is about giving your SCADA system a way to turn a serious alarm into a short, urgent text that lands on the on-call person's phone, with enough discipline built in that the alerts stay trustworthy rather than becoming a nightly nuisance that people silence. Because a text is intrusive by design, the bar for sending one is higher than for an email: only the alarms that genuinely warrant waking someone should trigger a text, and the system needs guardrails so a chatter of alarms does not fire off a hundred messages at midnight. This guide covers connecting an SMS gateway or provider, choosing which alarm priorities trigger a text, adding the on-call numbers, applying throttling and quiet hours, and testing that a real alert actually sends.
How to set up SMS alerts in one line: To set up SMS alerts in SCADA, first connect a way to send text messages, either an SMS gateway device with a cellular modem and SIM at the site or an internet-based SMS provider service, and enter its settings. Then build a notification rule that sends a text only for high-priority alarms that genuinely warrant reaching someone, and add the on-call phone numbers as recipients. Add throttling so a burst of alarms cannot fire off dozens of texts, and quiet-hour or on-call scheduling so routine alerts do not wake people needlessly, then send a test alert to confirm a real text arrives before you depend on it.
There are two common ways for a SCADA system to send a text, and the first choice is which one fits your situation. One is a physical SMS gateway, a small device with a cellular modem and a SIM card that the SCADA system hands messages to, and which sends them over the mobile network directly. This has the advantage of not depending on an internet connection to send, which can matter at a remote site whose only comms is the same cellular link, and it keeps the sending self-contained. The tradeoff is that it is hardware you have to install, power, and maintain, with a SIM and a plan of its own, and it can only send as fast as one modem allows.
The other approach is an internet-based SMS provider, a hosted service that accepts a request from the SCADA system over the network and sends the text on your behalf through its own infrastructure. This needs no local hardware beyond the site's existing internet connection, scales easily to many messages and many sites, and is simple to set up by entering the provider's account credentials and endpoint into the SCADA system. Its dependence on an internet connection is the main caveat, since if the site or the central system loses connectivity the provider cannot be reached, so for critical alerting some operations use a provider for convenience with a fallback path in mind. Choosing between a local gateway and a hosted provider comes down to whether self-contained sending or hands-off scalability matters more for your sites.
Whichever path you choose, the setup step is entering the connection details so the SCADA system can reach it, the device settings and SIM for a gateway, or the account credentials and service endpoint for a provider, along with a sender identity where required. As with email, this is a link that can fail quietly if a credential or setting is wrong, so the configuration has to be exact and it has to be tested with a real message later. It is also worth knowing that many SMS providers require the recipient numbers to be in a particular format and may have their own sending limits and costs per message, which feeds directly into how you design the rules and throttling so you are not paying for or triggering floods of texts.
A text is intrusive by nature, so the rule for what triggers one should be stricter than for an email. The right filter is again alarm priority, but set higher: reserve SMS for the alarms serious enough to justify interrupting someone's evening or waking them up, the critical conditions where a delayed response means real damage or lost production. A HI-HI on a critical vessel or a site-down condition earns a text; a routine warning does not. Getting this threshold right is the difference between an SMS system people trust and respond to and one they mute after the third pointless 2 a.m. buzz, because the moment texts start arriving for things that did not need a text, their urgency is gone.
The recipients for SMS are phone numbers, and the concept that matters here is the on-call rotation, because the person responsible for responding is usually not the same every night. Rather than texting a fixed list forever, a good setup routes alerts to whoever is currently on call, and it is worth arranging escalation so that if the first on-call person does not acknowledge within a set time, the alert moves to a second number, a backup or a supervisor. This ensures a serious alarm is not lost because the one person on the list was unreachable, and it mirrors how field operations actually staff their coverage. Keeping the on-call numbers current, and updating them as the rotation changes, is an ongoing responsibility, since a text sent to a stale number is a silent failure at the worst time.
Throttling is the guardrail that keeps SMS from turning against you, and it is more important for text than for email because texts are intrusive and often cost money per message. When a site has a real upset, one root problem can set off a cascade of related alarms in seconds, and without a limit that could fire dozens of texts to the on-call phone in a minute, which is both expensive and useless, since the person only needs to know something is wrong, not receive forty separate buzzes. Throttling caps how many texts go out in a window, or consolidates a burst into a single summary message, so an alarm flood produces one clear alert rather than a barrage. Configuring a sensible rate limit is what keeps the SMS channel usable during exactly the events it exists to cover.
Quiet hours are the setting that respects the human on the other end while still covering genuine emergencies. Not every alarm that warrants a text during the workday warrants waking someone at 3 a.m., so a good SMS setup can suppress lower-tier texts outside working hours while still letting the truly critical ones through, or route off-hours alerts only to the designated on-call person rather than the whole team. The aim is that people are woken only when it genuinely matters, because an SMS system that buzzes for non-emergencies at night quickly gets its notifications silenced, which defeats the entire purpose. Deciding which alarms are urgent enough to break quiet hours, and which can wait until morning, is a policy decision worth making deliberately rather than by default.
Because so many links in the SMS chain can fail without any visible sign, testing with a real message is non-negotiable. You trigger a test alarm at the priority that should send a text and confirm an actual text arrives on the on-call phone, with readable content, within a reasonable time. This proves the gateway or provider connection works, the rule fires, the number is right and correctly formatted, and the throttling and quiet-hour logic behave as intended. Testing also lets you check the message content, since a text has very little room, so the alert has to say the essential thing, which site and what is wrong, in a few words that make sense on a lock screen. An untested SMS setup is a promise you have not verified, and the emergency is a bad time to discover it was empty.
SMS alerting is arguably the single most valuable feature for genuinely unmanned sites, and cloud SCADA is what makes it dependable across a whole fleet. In a cloud SCADA platform such as Merobix, the alerting runs on the always-on hosted system connected to every site, so a critical alarm at a remote, unstaffed well or tank can send a text to the on-call person's phone no matter where they are and no matter that the site itself has no one and no local server keeping watch. Because the platform sees every site's alarms centrally, one set of SMS rules, with priority filtering, on-call routing, throttling, and quiet hours, can cover the entire operation, which is exactly what lets a small team responsibly run many sites that no one visits day to day. The SMS setup, done with the discipline in this guide, is what turns unmanned into monitored rather than merely unattended.
A physical SMS gateway with a cellular modem and SIM sends texts directly over the mobile network and does not depend on an internet connection, which suits a remote site, but it is hardware you must install, power, and maintain. An internet SMS provider is a hosted service that needs no local hardware beyond the existing internet connection and scales easily across many sites, but it depends on connectivity to reach the provider. The choice comes down to whether self-contained sending or hands-off scalability matters more for your sites.
Use throttling, which caps how many texts go out in a time window or consolidates a burst of related alarms into a single summary message. This matters more for SMS than email because texts are intrusive and often cost money per message, and one root problem can set off a cascade of related alarms in seconds. With throttling, an upset produces one clear alert instead of forty separate buzzes, which is both cheaper and far more useful to the on-call person, who only needs to know something is wrong.
Reserve SMS for the most serious alarms, the critical conditions where a delayed response means real damage or lost production, because a text is intrusive by design and interrupting or waking someone should be justified. Emails suit a wider range of lower-priority notifications that someone will read in due course. Setting the SMS priority threshold high, and using quiet hours so only truly urgent alerts break through at night, is what keeps people trusting and responding to texts rather than muting them after the first pointless middle-of-the-night buzz.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.