Email, SMS or WhatsApp: choosing an alert channel in Kenya
An alert that is not read is not an alert. Choosing the channel is as much a decision as choosing what to monitor, and the right answer in Kenya is not the same as the right answer in a market where everyone lives in Slack.
Email: good for records, poor for waking people
Email is free, rich and searchable. It is also the worst channel for an urgent page: it arrives in a tray nobody watches at 3 a.m., and on a phone it competes with marketing mail for attention.
Where email earns its place:
- a durable record of every incident, for audit and for the post-mortem
- low-severity notices — a certificate entering a 30-day warning window, a monitor paused by a colleague
- daily digests for management, who will never read a per-event alert
SMS: the channel that actually wakes someone
SMS is expensive per message and plain text only. It is also the one channel with no app to keep open, no notification settings to fight, and no data requirement when the network is degraded — which is exactly when you are being paged.
Use SMS for downtime of revenue-critical endpoints only. Two reasons: cost, and the fact that an SMS channel used for everything becomes as ignorable as an email channel within a month.
A useful pattern is a very short first message — "Portal DOWN since 03:12" — with the detail left in the dashboard and the email.
WhatsApp: where Kenyan teams actually coordinate
For many operations teams WhatsApp is the working environment: it is where the person on call already is, and a message in a familiar group gets a faster human response than an SMS from an unknown shortcode.
Its weakness is process. WhatsApp groups are informal; they have no acknowledgement, no escalation and no reliable record of who saw what. Treat WhatsApp as notification, not as an incident system.
WhatsApp also has a practical constraint worth knowing before you design around it: business messaging runs through the official API with template messages and per-conversation pricing, so it is not a drop-in replacement for a free webhook.
Slack and Discord: excellent if the team lives there
If your engineers already work in Slack, a channel is the best possible default: threaded context, links, and a searchable history. If they do not, it is the fastest way to build an alerting channel nobody reads.
Route by severity, not by preference
The channel should follow the consequence:
| Severity | Example | Channel |
|---|---|---|
| Revenue down | Checkout, payment callback | SMS + WhatsApp, then email |
| Service degraded | Portal 5xx, DNS failing | WhatsApp + email |
| Attention soon | Certificate expiring in 14 days | |
| Record only | Monitor created, paused | Audit log |
The failure mode nobody plans for
Whatever you choose, decide what happens when the notifier itself fails. A webhook URL that returns 404, an SMS account with no credit, a mailbox over quota — all of them produce silence, and silence looks exactly like "everything is fine".
Two habits fix this cheaply:
- Test the channel before you rely on it. PIMA has a Send Test button on every channel for exactly this reason; it exercises the real delivery path.
- Keep the delivery log. If every attempt is logged with its error, "why did nobody get the alert" becomes a two-minute question instead of a rumour.
Finally, close the loop: monitor the monitor. An external heartbeat check that notices when your monitoring stops running is the only way to know that silence is genuine.