Phone push notifications are easy to miss, silence, or lose in a crowded notification tray, a real risk for genuinely critical IoT alerts. SMS and email remain the most reliable channels for cutting through, and a VPS running Node-RED can send both directly, SMS via a pay-per-message API like Twilio, email via a standard SMTP relay, without committing to a SaaS alerting platform’s recurring per-seat or per-alert subscription.
Why push notifications alone aren’t enough for critical alerts
Every guide on this site covering alerting, cold chain excursions, fleet connectivity loss, backup failures, has assumed a notification reaching someone reliably. Phone push notifications, while convenient, have real failure modes worth taking seriously for genuinely critical situations: a phone on silent overnight, a notification accidentally dismissed without being read, an app that’s been force-closed by the operating system to save battery. SMS, by contrast, generally still produces an audible alert even when a phone’s notification settings would otherwise suppress an app notification, and email provides a durable, easily forwarded and escalated record that a push notification doesn’t.
Sending SMS from Node-RED via Twilio
Twilio, a well-established API-based SMS provider, is the most common choice for this pattern, with a straightforward HTTP request node in Node-RED handling the actual sending:
// Node-RED function node, building the Twilio API request
msg.headers = {
'Content-Type': 'application/x-www-form-urlencoded'
};
msg.payload = "To=" + encodeURIComponent("+447xxxxxxxxx") +
"&From=" + encodeURIComponent("+1xxxxxxxxxx") +
"&Body=" + encodeURIComponent("ALERT: Freezer 2 temperature excursion at Site A");
return msg;That payload feeds into an HTTP request node configured for Twilio’s Messages API endpoint, with Twilio account credentials supplied via Basic Auth. This follows directly from the threshold-alerting Node-RED patterns covered throughout this site’s other guides, the SMS-sending step simply replaces or supplements whatever notification method was used there.
Setting up email alerting via SMTP relay
For email, Node-RED’s built-in email node handles sending directly via any SMTP relay, either a transactional email API (SendGrid, Mailgun and similar all offer SMTP relay endpoints) or, for lower volume, a properly configured Postfix instance running directly on the VPS itself:
sudo apt install postfix
# Configure as a 'Satellite system' during setup,
# relaying outbound mail through your chosen provider's SMTP relay
# rather than attempting direct delivery, which most VPS IP ranges
# have reduced deliverability for due to spam filteringWorth being clear about this distinction: running your own SMTP server to relay through a reputable provider is straightforward and reliable; attempting to send mail directly from a VPS’s own IP address, without relaying through an established provider, frequently lands in spam folders or gets blocked outright, since VPS IP ranges are heavily targeted by spam filters regardless of legitimate use. Relaying through a provider with established sender reputation avoids this entirely.
Cost comparison against dedicated SaaS alerting platforms
| Approach | Cost structure |
|---|---|
| Dedicated SaaS alerting/incident platform | Often per-seat or per-alert-volume subscription |
| Self-hosted via Node-RED + Twilio/SMTP relay | VPS cost (already covered elsewhere) plus genuinely pay-per-message SMS costs, no platform subscription |
For the alert volumes typical of the projects covered throughout this site, occasional genuine alerts rather than high-frequency notification streams, the self-hosted approach’s cost is usually dominated by the per-SMS cost itself (a small fraction of a pound per message with most providers), not any platform fee, since there isn’t one.
Building a sensible escalation chain
This is the same escalation principle covered in Cold Chain and Asset Monitoring Dashboards, generalised here: a Node-RED flow sending an initial notification through a lighter-weight channel (email, or a push notification via the patterns covered in this site’s smart home guides), escalating to SMS if unacknowledged within a defined window, is more robust than relying on any single channel alone. Building this with a simple acknowledgement mechanism, a webhook the recipient can trigger to confirm receipt, lets the escalation logic distinguish between “alert sent” and “alert actually seen by someone”.
A note on rate limiting and runaway alerts
Worth building in deliberately: a cap on how many SMS messages a single alert condition can trigger within a given period, preventing a flapping sensor (rapidly toggling between alert and normal state) from generating dozens of SMS messages and the associated cost, or simply becoming noise that gets ignored. The same debounce logic covered throughout this site’s threshold-alerting guides applies directly here.
Where IoTMail fits into this picture
For projects wanting a more integrated, purpose-built email and notification layer rather than assembling Postfix and API calls by hand, IoTMail is worth knowing about as a more turnkey option specifically aimed at IoT and device-originated email and alerting use cases, complementary to the self-hosted Node-RED approach covered in this guide rather than a strict alternative to it.
Frequently asked questions
Is SMS via Twilio genuinely cheaper than a dedicated alerting SaaS platform?
For low to moderate alert volumes, typically yes, since you’re paying only Twilio’s per-message rate with no platform subscription layered on top; for very high alert volumes, it’s worth comparing actual costs directly, since dedicated platforms sometimes offer volume pricing that changes the comparison at scale.
Can this same setup send WhatsApp messages instead of SMS?
Yes, Twilio and several other providers support WhatsApp Business API messaging through a very similar integration pattern to SMS, worth considering if your alert recipients are more reliably reachable via WhatsApp than traditional SMS.
Does sending email this way risk the VPS’s IP address getting blacklisted?
Not if relaying through an established provider’s SMTP service as described in this guide, since the provider’s own reputation, not the VPS’s IP, handles final delivery. Attempting direct delivery from the VPS’s own IP without relaying is the scenario that carries real blacklisting risk.
How reliable is SMS delivery compared to email or push notifications?
Generally very reliable for typical UK mobile numbers via an established provider like Twilio, though no channel is ever entirely guaranteed; this is exactly why the escalation-chain approach covered in this guide, rather than relying on any single channel, is the more robust pattern for genuinely critical alerts.
Can I test this alerting setup without risking spamming real recipients during development?
Yes, most SMS and email providers offer sandbox or test modes, and it’s worth using a personal test number and email address during development before pointing the flow at genuine alert recipients, the same testing discipline worth applying to any automation before trusting it with real, time-sensitive alerts.
Is it worth logging every alert sent, not just sending it?
Yes, a simple log of every alert sent, timestamped and stored alongside the rest of a project’s data (in InfluxDB or even just a Node-RED-managed log file), is genuinely useful for later reviewing alert frequency and effectiveness, and for confirming during any post-incident review exactly when an alert was actually sent.
Bringing this together with everything else on the site
This guide is deliberately the final piece connecting back to nearly every other guide on this site: the cold chain monitoring, multi-site aggregation, backup verification and uptime monitoring guides all reference sending an alert at some point, and this is the guide covering how that actually happens at the message-delivery level, the Twilio API call or the SMTP relay underneath every “send an alert” step described elsewhere. Building this piece early, even with a simple initial implementation, means every other guide’s alerting logic has somewhere real to send its output from day one, rather than each project reinventing notification delivery separately as the need arises.
A final word on choosing channels deliberately, not by default
It’s worth resisting the temptation to wire every alert to every channel simultaneously, SMS, email and push notifications all firing for every single event regardless of severity. Matching channel to genuine urgency, a routine daily summary by email, a sustained critical threshold breach by SMS, keeps each channel meaningful rather than training recipients to tune out a constant stream of low-priority noise delivered with the same urgency as something that actually needs immediate attention. This deliberate matching of channel to actual stakes is, in the end, the same underlying discipline that runs through every alerting and monitoring guide on this site: build something that genuinely gets noticed when it matters, not something that’s merely technically functional.
Frequently asked questions
Is SMS via Twilio genuinely cheaper than a dedicated alerting SaaS platform?
For low to moderate alert volumes, typically yes, since you’re paying only Twilio’s per-message rate with no platform subscription. For very high alert volumes, dedicated platforms sometimes offer volume pricing that changes the comparison at scale.
Can this setup send WhatsApp messages instead of SMS?
Yes, Twilio and several other providers support WhatsApp Business API messaging through a very similar integration pattern to SMS, worth considering if your alert recipients are more reliably reachable via WhatsApp.
Does sending email via a VPS risk IP blacklisting?
Not if relaying through an established provider’s SMTP service as described in this guide, since the provider’s own reputation handles final delivery. Attempting direct delivery from the VPS’s own IP without relaying is the scenario that carries real blacklisting risk.
Can I test this without spamming real recipients during development?
Yes, most SMS and email providers offer sandbox or test modes. Always test against personal numbers and addresses before pointing flows at genuine alert recipients.
Is it worth logging every alert sent?
Yes, a simple timestamped log in InfluxDB or a Node-RED-managed log file is useful for reviewing alert frequency, confirming delivery, and supporting any post-incident review of exactly when an alert was sent.
Structuring alerts by severity tier
The most durable alerting architectures distinguish between at least two tiers: informational alerts worth knowing about but not urgent, and critical alerts requiring immediate attention. The practical pattern for this in Node-RED: use a function node to classify incoming MQTT events by severity based on the specific condition, then route through different notification channels accordingly. Informational events, a daily summary of overnight temperature ranges from the cold chain sensors, a battery status report, go to email where they sit for later reading. Critical events, a sustained temperature excursion, a device that’s gone offline unexpectedly, a backup that didn’t complete, go to SMS or a push notification service that produces an audible alert regardless of phone notification settings. This two-tier routing prevents the channel saturation that occurs when everything uses the same channel at the same priority level.
Rate limiting alerts in Node-RED
Node-RED’s built-in rate limiting nodes prevent a misbehaving sensor or a rapidly oscillating threshold from generating dozens of alerts in quick succession. The delay and rate-limit nodes provide a straightforward way to implement a minimum interval between alerts for any given condition, such that a freezer temperature sensor bouncing around a threshold once every thirty seconds doesn’t result in a phone call every thirty seconds. The specific interval depends on the condition: for genuinely urgent situations a five-minute minimum interval is typically aggressive enough; for less critical conditions that might be noisy, a per-hour rate limit is more appropriate. Building this in from the start, rather than after the first incident where a flapping sensor generates fifty SMS messages before anyone notices, is worth the few extra nodes it requires.
Email as a daily summary channel
One of the most underused alerting patterns for self-hosted IoT: a scheduled Node-RED flow that generates a daily summary email rather than alerting on individual events. A single email arriving each morning with yesterday’s sensor ranges, any events that occurred, and current system status gives a useful ambient awareness of whether everything is normal without requiring anyone to open a dashboard. For a business using this infrastructure to monitor something that needs daily review anyway, cold chain temperature records, energy consumption, equipment run-hours, this is more useful than waiting for individual alerts that may or may not trigger depending on whether conditions hit configured thresholds. Node-RED’s inject node with a cron-style schedule combined with an email node and a function node that queries InfluxDB for the previous 24 hours’ data covers the entire pattern with a handful of nodes.
The broader alerting philosophy this reflects
The alerting approach covered in this guide, and throughout this site’s other guides where alerting comes up, shares a consistent underlying philosophy: alerts should be meaningful, channels should match urgency, and silence should be informative rather than assumed to mean nothing is wrong. An alerting system that generates noise trains its recipients to ignore it. One that sends nothing trains them to not rely on it. The target, a system that only alerts when something actually needs attention, and that definitely alerts when it does, is achievable at the scale and budget of projects this site covers without sophisticated tooling, just deliberate design.