Email is the oldest and easiest way to get an alarm off a SCADA system and in front of a person. A monitoring platform composes a message describing the alarm and hands it to a mail server over SMTP, and it arrives in an inbox like any other email. That simplicity is exactly why email is so widely used and also why it is the wrong choice for alarms that cannot wait. This guide explains how an email alarm notification works, why it is fine for informational and low-priority alerts but unreliable for time-critical ones, and how email-to-SMS bridging lets a mailbox reach a phone.
Email alarm notification in one line: An email alarm notification is an alarm delivered to a recipient's mailbox as an email message, sent by the monitoring system through a mail server using SMTP. It is a good fit for informational and low-priority alarms where a delay of minutes does not matter, but it is a poor channel for time-critical alarms because spam filtering, mailbox polling intervals, and the lack of guaranteed delivery mean a message can be delayed, buried, or silently dropped without the sender ever knowing.
When an alarm condition is detected, the monitoring system builds a message: a subject line that usually names the site and the alarm, and a body that carries the tag, the value, the priority, and a timestamp. It then connects to a configured outbound mail server and hands the message over using SMTP, the standard protocol for sending mail. From that point the alarm is an ordinary email travelling through the same infrastructure as every other message, relayed from server to server until it reaches the recipient's mailbox provider and is filed for the person to read.
The appeal of this path is that it requires almost nothing special. Nearly everyone already has an email address, mail servers are ubiquitous, and adding a recipient is as simple as typing an address into a distribution list. There are no carrier accounts to set up as there are with dedicated text messaging, and a single email can reach many people at once by listing several addresses. For a supervisor who wants a copy of every daily rollup or a maintenance planner who wants to know when a filter needs attention, dropping the alarm into a mailbox is entirely sufficient.
Email also carries more than a short line of text. It can include a longer description, a table of related values, and links back to the relevant screen in the monitoring platform, which a constrained channel like a plain text message cannot. For informational content where the reader will act during normal working hours rather than in the next few minutes, that richer format is a genuine advantage over a terse alert.
The same properties that make email easy make it untrustworthy for alarms that must be seen quickly. Email is a store-and-forward system with no promise of prompt delivery. A message can sit in an outbound queue, be greylisted and deferred by the receiving server, or be delayed anywhere along the relay chain, so the gap between an alarm firing and a person reading it is unpredictable and can stretch to many minutes or longer. For a low tank level that will not become critical for hours that is harmless, but for a condition that needs a response now it is unacceptable.
Spam and junk filtering adds a second hazard. Automated alarm mail, sent repeatedly from the same address with similar subject lines, is exactly the pattern that filters treat as suspicious, so an alarm can be quietly diverted to a junk folder the recipient never checks. Because the message technically arrived, nothing looks wrong from the sender's side, yet the person never sees it. Mailbox polling makes this worse still: a phone or client that only checks for new mail every so often, or that suppresses notifications, adds its own delay on top of everything else.
The deepest problem is the absence of delivery proof. When an alarm is important, the operation needs to know that a human actually received it, and standard email offers no reliable confirmation of that. There is no dependable read receipt and no built-in acknowledgment path, so email cannot close the loop the way a channel designed for critical alerting does. For this reason, email should be treated as best-effort notification for informational and low-priority alarms, while genuinely time-critical alarms belong on channels that confirm delivery and support acknowledgment and escalation.
A common way to stretch email toward urgency is email-to-SMS bridging, where the alarm is emailed to a special gateway address that a mobile carrier converts into a text message on a phone. This can put an alarm in front of someone who is away from a screen, and it costs nothing beyond an ordinary email to set up. It inherits every weakness of email, though: the message still travels through spam-prone, unconfirmed mail infrastructure before it even reaches the gateway, gateway addresses change and are sometimes retired, and the delivered text is often truncated. It is a convenient bridge, not a substitute for direct, purpose-built text or voice alerting.
In a cloud SCADA platform such as Merobix, email is best understood as one notification channel among several, chosen deliberately by alarm priority rather than used for everything. Informational and low-priority alarms, digests, and daily reports fit email well, since the reader will act in normal time and benefits from the richer content and easy distribution. High-priority alarms are routed to channels that confirm delivery, support acknowledgment, and escalate to the next responder if the first does not reply, so the operation is never depending on a message that might be sitting in a junk folder.
Field operations reinforce this split. A pumper covering remote wells cannot rely on an inbox for a shutdown that needs attention within minutes, but the same person is well served by an emailed summary of the shift's minor events. Using email where its unhurried, best-effort nature is acceptable, and reserving confirmed channels for the alarms that cannot be missed, is the discipline that keeps email a useful part of a notification strategy rather than a hidden single point of failure.
No. Email is a best-effort, store-and-forward channel with no guaranteed delivery time and no reliable proof that a person received the message. Spam filtering, deferred relays, and slow mailbox polling can delay or bury a critical alarm without the sender ever knowing. Critical alarms should use channels that confirm delivery, support acknowledgment, and escalate when the first responder does not reply.
The most common causes are spam filtering that diverts repetitive alarm mail to a junk folder, greylisting or queuing that defers the message on the receiving server, and infrequent mailbox polling on the recipient's device. Because email has no delivery guarantee, any of these can happen silently. Checking junk folders, allowlisting the sender address, and reserving email for non-urgent alarms all reduce the impact.
The alarm is sent as an email to a special carrier gateway address that converts it into a text message on the recipient's phone. It is a cheap way to reach someone away from a screen, but it inherits every weakness of email, including spam filtering, delivery delays, and truncated content, and gateway addresses can change. It is a convenient bridge rather than a dependable substitute for direct text or voice alerting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.