An alarm on a screen only helps someone who is looking at the screen, and at a remote or unmanned site nobody is. An email notification bridges that gap, taking an alarm that fires in the SCADA system and pushing it out to a person's inbox wherever they are, so a problem at a distant pump station reaches the on-call engineer at home. Configuring this well is a chain of four links that all have to hold: the system needs a way to actually send email, a rule that decides which alarms warrant a message, a list of who receives it, and a message clear enough to act on. Miss any one and the notifications either never arrive, arrive for everything until people ignore them, or arrive so vaguely that nobody knows what to do. This guide walks through the whole chain: entering the SMTP settings that let the system send mail, building a notification rule scoped by priority, adding recipients and a message template, and testing that a real alarm actually lands in the inbox.
How to configure an email alarm notification in one line: To configure an email alarm notification in SCADA, first give the system a way to send mail by entering the SMTP or relay server settings, the server address, port, encryption, and any login credentials, and a from address. Then build a notification rule that defines which alarms trigger an email, usually filtered by priority so only serious alarms notify, and add the recipients who should receive it. Attach a message template that includes the tag, the condition, the value, and the time so the email is actionable, then send a test alarm to confirm it actually arrives before you rely on it.
Before the SCADA system can email anyone, it needs an email server to hand its messages to, and configuring that connection is the SMTP setup. SMTP is the standard protocol for sending mail, and the settings are the address of the mail server, the port it listens on, whether the connection is encrypted, and, in almost all cases now, a username and password or other credentials the server requires before it will accept mail. You also set a from address, the sender the notifications appear to come from, which recipients will see and may filter on. These values come from whoever runs the email service, an internal IT mail server or a hosted email provider, and they have to match exactly or the server simply refuses to relay the message.
SMTP is also where notifications most often silently fail, because modern mail servers are strict about who they will send mail for, and for good reason, since an open relay is a spam magnet. A server will reject messages that lack proper authentication, that come from an unexpected from address, or that arrive over the wrong port or without the expected encryption. So getting these settings precisely right is not a formality; a single wrong value, an incorrect port, a missing password, encryption turned off when the server demands it, means every notification is quietly rejected while the SCADA system may still think it sent them. This is why testing later is essential, because the SMTP link fails invisibly more often than any other part of the chain.
There is also the deliverability question that lives beyond the SCADA settings themselves. Even a correctly configured SMTP connection can have its messages land in a spam folder or be dropped if the sending domain is not properly set up to authorize the mail server, or if the from address looks suspicious to the receiving side. This is usually an IT and email-administration matter rather than a SCADA one, but it is worth being aware that configuring SMTP correctly gets the message accepted by your sending server, while getting it reliably into recipients' inboxes can also depend on the broader email setup. Coordinating with whoever manages the mail service is the practical way to make sure alarm emails not only send but actually arrive.
With a working way to send mail, the next step is deciding which alarms should generate an email at all, because emailing every alarm is a fast way to train everyone to ignore the emails. This is the notification rule, and the most common and useful filter is alarm priority. You configure the rule so that only alarms above a chosen priority send an email, so a critical HI-HI on a vessel notifies someone while a low-priority informational alarm does not. Filtering by priority is what keeps the notifications meaningful, because an inbox flooded with trivial alarm emails becomes noise that people mute, and then the one email that mattered goes unread among the rest.
Notification rules can usually filter on more than priority, and using those filters deliberately makes the notifications sharper. You might scope a rule to a particular area or set of sites, so the person responsible for the north field only gets north field alarms, or restrict it to certain alarm types, or even to certain tags. The goal throughout is that each recipient gets exactly the alarms that are theirs to act on and none of the ones that are not, because a recipient who receives alarms they cannot do anything about learns to stop reading them. Matching the rule's scope to a real person's actual responsibility is what makes the notification a useful prompt rather than background clutter.
The recipients are the people or lists the rule sends to, and choosing them is more consequential than it looks. A rule can send to a single person, several people, or a distribution list, and the right choice depends on who genuinely needs to know and who can act. For a critical alarm you may want more than one recipient so a message is not lost if one person is unreachable, while for routine notifications a single owner or a shared inbox is enough. It is also worth thinking about escalation, arranging that if the first recipient does not respond, the alarm reaches a second person after a delay, so a serious condition does not sit unacknowledged because the one person on the list happened to be asleep or away. Keeping the recipient lists current as people change roles is an ongoing task, because a notification sent to someone who left the company is a silent failure of the whole chain.
The message template is what the recipient actually reads, and a good one turns a raised alarm into an actionable prompt. The template should include the essentials automatically pulled from the alarm: which site and equipment, what the condition is, the actual value that triggered it, and the time it occurred, all in plain language rather than cryptic codes. An email that says only PT-301 HI forces the recipient to log in and investigate before they even understand the problem, while one that says North Station Well 3 discharge pressure high at 118 psi at 2:14 a.m. tells them most of what they need before they touch a keyboard. Writing the template for someone reading it half-awake on a phone, who may not know this site well, is the same discipline that makes any alarm message useful.
No notification setup is finished until a real alarm has been driven through the whole chain and confirmed to arrive, because so many links can fail silently. You trigger a test alarm that matches the rule, at or above the priority that should notify, and confirm the email actually lands in the recipient's inbox, with the right content, not stuck in a spam folder or lost at the mail server. This end-to-end test is the only thing that proves the SMTP settings, the rule, the recipient list, and the template all work together, and it catches the invisible failures, a rejected relay, a filtered-out priority, a typo in an address, while they are still easy to fix. Skipping the test means the first time you learn the notifications do not work is during the emergency they were supposed to warn you about.
Email notification is one of the strongest arguments for cloud SCADA, because it turns a fleet of unmanned sites into something a small team can watch from anywhere. In a cloud SCADA platform such as Merobix, the notification engine runs on the hosted system that is always online and always connected to the sites, so an alarm at a remote well reaches the on-call person's phone even though no one is anywhere near the site and no local server has to stay running to send the mail. Because the platform already sees every site's alarms in one place, a single set of notification rules can cover an entire operation, routing each site's serious alarms to the right people by priority and area, which is exactly what makes remote, lightly staffed operations viable rather than a gamble on someone happening to notice a problem in time.
The most common cause is an SMTP configuration that the mail server silently rejects, because modern servers are strict about authentication, the from address, the port, and encryption, and a single wrong value means every message is refused while the system may still think it sent them. Beyond that, even accepted mail can land in spam or be dropped if the sending domain is not set up to authorize the server. The only way to know is to trigger a real test alarm and confirm it actually arrives, and to coordinate with whoever manages the mail service.
No, and doing so is a fast way to make people ignore the notifications. The right approach is a notification rule that filters by priority so only serious alarms email someone, while low-priority informational alarms do not. An inbox flooded with trivial alarm emails becomes noise that recipients mute, and then the one email that mattered goes unread among the rest. Scoping rules by priority, and by area or site so each person gets only the alarms that are theirs to act on, keeps the notifications meaningful.
It should contain everything the recipient needs to understand and act without first logging in: which site and piece of equipment, what the condition is, the actual value that triggered it, and the time, all in plain language. An email that shows only a cryptic tag name forces the recipient to investigate before they even grasp the problem. Writing the template for someone reading it half-awake on a phone, who may not know that particular site, is what turns the notification into an actionable prompt rather than a puzzle.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.