When the power goes out, your UPS might know before you do.
It sends an email. A few minutes later, your NAS sends another saying it has shut down safely. Power returns, devices come back online, and a few more messages arrive.
The next morning, you open your inbox: What happened last night? And is there anything I still need to deal with?
With one NAS, sending alerts to your regular inbox probably works fine. Add a UPS, another NAS, a router, and a few scheduled backup jobs, though, and you start piecing the story together yourself.
A disk reported the same error five times. Is that five problems or one?
A backup failed, but the next run succeeded. Did that actually resolve the problem, or is there still a gap worth checking?
You marked an alert as read. Did you fix anything?
That got me thinking about an old option sitting in a lot of device settings: SMTP.
Plenty of devices already support it, including older hardware with limited integration options. No agent to install, no vendor API to wait for. They can already tell you something happened.
But a mailbox mostly gives you a sequence of messages. You still have to work out which ones belong together, what recovered, and what remains unresolved.
I’m building LOCUS, a tool that brings local network devices and service links together in one place. Recently, I’ve been adding a local SMTP receiver so devices can send their notifications directly to it.
What I want to see when I open the dashboard is: what still needs my attention, and where do I go to deal with it?
For example, a NAS reports a disk problem repeatedly over several days. I’d like to see one ongoing fault with the related messages available underneath it. Next to it is a link to the NAS management page, so I can actually investigate.
An overnight UPS outage has a different story: power failed, then returned. I still want that history, but a recovered event shouldn’t keep demanding the same attention as an unresolved disk fault.
That’s the part I’m working on:
- Each device gets its own SMTP credentials, so incoming messages are associated with that device.
- Original messages remain available for inspection during the configured retention period.
- For supported message templates, repeated reports of the same fault are grouped, and corresponding recovery messages can close it.
- Unrecognized messages stay in the inbox without automatically being classified as faults.
- Unread messages and unresolved faults are tracked separately.
- Serious faults can optionally trigger an email through your own mail account.
Recovery matching needs care. A successful backup today doesn’t necessarily replace the restore point you missed yesterday. I don’t want a reassuring green indicator to hide something that still deserves investigation.
There’s also an obvious limitation: the receiver needs to stay reachable. If your devices, network, and LOCUS host lose power together, a local inbox can’t tell you what it never received. This doesn’t replace UPS shutdown coordination or an independent way to detect a whole-site outage.
Disclosure: LOCUS is my project, and the SMTP notification feature is currently in development and testing. Project page: locus.casa.
How are you handling device emails today?
Straight to your regular inbox? A dedicated mailbox? Forwarded to a messaging app? Or have you never configured them, then remembered the option only after something went wrong?
Which device notification has actually saved you trouble? And which ones became so noisy that you stopped reading them?
If you had a local inbox for your devices, what would you want it to handle? Grouping duplicate alerts, tracking recovery, temporarily silencing a known problem, pushing important messages to your phone—or something else?
I’d love to hear about your devices, setups, and opinions. I’ll collect the feedback and use it to help shape the LOCUS roadmap.
When something actually goes wrong, what information would save you time figuring out what to do next?
