SMS alerts for critical incidents with Uptime Kuma

Email and chat alerts are enough for most monitoring needs most of the time. But for genuinely critical incidents — the kind that need someone's attention regardless of whether they are at a keyboard — SMS remains the most reliable way to reach a human. A text message cuts through do-not-disturb rules, is delivered via the carrier network rather than the internet, and arrives on the most basic phone every member of the team carries. This guide walks through the practical side of wiring Uptime Kuma into SMS alerts for UK teams, including the discipline required to keep SMS useful rather than expensive. If you are new to Uptime Kuma altogether, start with our plain-English introduction.

When SMS is the right channel

SMS has four particular strengths as an alert channel.

Delivery independence. SMS goes through the mobile carrier, not the internet. If the wifi, the home broadband and the data connection are all down, SMS still arrives as long as the phone has any cellular signal. For critical infrastructure monitoring, this independence matters — an alert about your primary internet going down is not much use if it is only delivered over your primary internet.

Breakthrough on silent phones. Most UK engineers configure do-not-disturb for overnight hours to silence chat notifications and app pings. SMS is typically exempt from these rules by default, or can be easily whitelisted. An SMS from the on-call monitoring system wakes the recipient; a Slack ping at 3am might not.

Universal device support. Every phone receives SMS. There is no app to install, no token to configure on the recipient's end, no licence to buy. If the on-call engineer's work phone is replaced, the new phone receives SMS immediately without any configuration.

Implicit urgency. Because SMS is rarer than email or chat for automated systems, a text from the monitoring system is self-flagging as important. Recipients take it seriously in a way they may not take a Slack ping.

SMS is, therefore, the right channel for genuinely critical alerts only. It is not a general-purpose notification channel, and using it as one is expensive in both money and goodwill. For non-critical alerts, email and chat as covered in our SMTP notifications guide and Slack and Teams guide are the right tools.

Which SMS providers work with UK numbers

Uptime Kuma supports several SMS providers natively. The ones worth considering for UK phone numbers are:

For UK teams without strong existing supplier relationships, the default recommendation is Twilio (if reliability and global reach matter most) or ClickSend (if UK pricing is the deciding factor). Both integrate cleanly with Uptime Kuma and both handle UK mobile numbers well.

Two other considerations when picking a provider. First, many UK teams prefer a provider with a UK support presence — someone on local hours who can be rung on the phone if SMS delivery mysteriously stops on a Sunday morning. That narrows the field considerably; Twilio and ClickSend are both accessible in UK working hours, even if their support headquarters are not literally in Britain. Second, compliance. UK regulated businesses (finance, healthcare, public sector) sometimes have specific data-residency or supplier-vetting requirements that rule out certain international providers. Check these requirements before signing up, not after.

For smaller UK teams without those constraints, the practical difference between Twilio and ClickSend is often just cost. Budget £1-2 per recipient per month for normal volumes.

Cost per message and budgeting

SMS is not free. A single UK SMS typically costs somewhere between 2p and 5p depending on provider, volume and origination. Those numbers are small individually; they add up.

A monitor that flips state 20 times a day (a flapping monitor is easily capable of this) at 5p per message is £1 per day or £30 per month. If you have multiple monitors flapping, or multiple recipients per alert, the number multiplies. A handful of misconfigured monitors can turn into £100/month of SMS bills before anyone notices.

The practical budgeting rule: estimate the expected monthly volume, multiply by 3, set that as the budget, and enable cost monitoring on the provider's account. Twilio and ClickSend both provide monthly spend dashboards and alerting on spend thresholds. A £10/month budget with a £30/month alert is sensible for a small UK business; teams with more aggressive monitoring or larger on-call rosters scale up from there.

Another cost consideration: some providers apply a minimum per-message charge plus a per-segment charge. A long SMS message that runs over 160 characters is billed as two segments. Keep alert messages concise — a monitor name and a status change is plenty — to stay within single-segment pricing.

A subtler cost factor is Unicode escalation. SMS messages composed entirely of standard GSM-7 characters get 160 characters per segment. Add a single non-GSM-7 character — an em-dash "—", a curly quote, an emoji — and the message silently transitions to UCS-2 encoding, which only allows 70 characters per segment. A short message that was going to cost one segment suddenly costs three, and the bill scales accordingly. Keep alert templates plain-ASCII where possible; Uptime Kuma's default templates already do this, but custom templates benefit from a sense-check.

Cost containment works on two sides: reducing the volume of SMS sent, and keeping each SMS short. Both matter. A team of eight on SMS alerts with ten critical monitors and well-tuned retries typically spends £20-30/month. The same setup with aggressive intervals, no retries and a broadcast recipient list can easily hit £200/month.

Setting up Twilio with Uptime Kuma

Twilio is the most commonly-used SMS provider for Uptime Kuma deployments. The setup:

1. Sign up for a Twilio account at twilio.com. The trial account includes enough credit to cover several dozen test messages.
2. Purchase a Twilio phone number capable of sending SMS to UK destinations. A UK origination number is best for deliverability; US or international numbers work but some UK carriers treat them with more suspicion.
3. From the Twilio Console, copy the Account SID and Auth Token. Treat both as secrets.
4. In Uptime Kuma, add a new notification channel and select Twilio as the type. Fill in Account SID, Auth Token, your Twilio phone number (in international format, for example +441234567890), and the destination phone number or numbers.
5. Test the notification. The SMS should arrive on the destination phone within a few seconds.

For multiple recipients, either create multiple notification channels (one per recipient) or supply a comma-separated list in the destination field if Uptime Kuma's version accepts it. Multiple channels are slightly more work to configure but give you finer routing control — per-recipient muting, per-recipient test results in the Uptime Kuma history.

Setting up ClickSend

ClickSend is often the better pick for UK-focused teams that do not need Twilio's broader ecosystem. The setup is similar:

1. Sign up for ClickSend and verify the account.
2. From the ClickSend dashboard, obtain the API username (your account username) and API key.
3. In Uptime Kuma, add a notification channel and select ClickSend as the type. Enter the API username, API key, sender (either a ClickSend-provided number or a named sender ID registered with the provider), and the destination UK mobile number.
4. Test.

ClickSend also supports named sender IDs in the UK — for example, sending as MonSystem rather than a numeric phone number. This can improve the recipient's ability to identify alerts, but registered sender IDs are regulated and require pre-approval with ClickSend. Worth doing if you send a material volume of SMS; not worth the paperwork for a team of three.

Keeping SMS reserved for emergencies

The single most important SMS-specific discipline is ruthless selectivity about which monitors page via SMS. Every monitor that sends an SMS should be on a shortlist of genuinely critical alerts. The shortlist typically includes:

• Customer-facing core services that generate revenue when up (homepage, checkout, primary API)
• Authentication systems that block everything else when they fail
• Payment or financial-data integrations where a prolonged outage has direct regulatory or commercial cost
• The Uptime Kuma instance itself (via an external probe, if you are self-hosting)

Everything else — certificate expiry warnings, DNS change notifications, staging environment issues, nightly batch job failures, non-critical integrations — goes to email or chat, not SMS. A good heuristic: if you would not get up from bed for the alert, it should not page via SMS.

Setting this discipline up front is much easier than retrofitting it. Every Uptime Kuma monitor defaults to "no notification channel"; assigning SMS to a monitor should be an explicit, reviewed decision. Many UK teams document a short "SMS-eligible monitors" list as part of their runbook and require a change request before adding anything to it.

A useful test: for each monitor on the SMS list, ask the team what they would do if it fired at 3am on a Sunday. If the answer is "fix it immediately, get out of bed" — SMS is the right channel. If the answer is "make a note to look at it Monday morning" — SMS is the wrong channel and the monitor should go to email or chat only. The 3am Sunday test is pragmatic and uncompromising, which is exactly what SMS budgeting requires.

Another part of the discipline is regular review. Every quarter, revisit the SMS-eligible list. Has any monitor joined the list because it once mattered but is no longer critical? Has a monitor that should be on the list been quietly downgraded? The list drifts over time and needs positive maintenance, not just inertia.

On-call rotation patterns

SMS really shines when combined with a formal on-call rotation. The common UK patterns:

Single on-call engineer per week. The rotating on-call engineer is the only SMS recipient on the critical monitors. Changing the rotation is a matter of editing the destination phone number in the Uptime Kuma notification channel. Simple; works for teams of 3-8 engineers.

Primary and secondary. Primary SMS goes to the on-call engineer. A delayed secondary SMS fires to a backup if the first alert is not acknowledged within 15 minutes. Uptime Kuma itself does not do escalation natively, but you can achieve this by routing through PagerDuty or Opsgenie — both of which handle acknowledgement and escalation and accept Uptime Kuma webhooks.

Time-window routing. SMS is active only during out-of-hours windows; during working hours, email or chat handles the load. Requires a small amount of scripting or conditional routing — again, easier through PagerDuty or Opsgenie than natively in Uptime Kuma.

Paired on-call. Two engineers are on-call simultaneously, with SMS going to both. Adds redundancy; halves the probability of a missed alert. Doubles the SMS cost.

For the broader view on how notifications fit into on-call strategy, our alert fatigue and notification strategy guide covers the whole picture.

A practical note on on-call handover: document clearly in the runbook how to update the SMS destination when the rotation changes. If the process involves a Slack message to one specific team member who makes the change in Uptime Kuma, and that team member is unavailable, the rotation stalls and the wrong person carries the on-call phone for an extra week. The handover should be automatable or, failing that, documented with several people able to execute it.

Another operational pattern worth considering: a weekly "on-call sanity SMS". At the start of each rotation, the system sends a test SMS to the incoming engineer confirming that the pipeline is working end-to-end. This catches the case where a provider account has expired, a phone number has been ported, or the on-call destination was mis-updated. It adds one SMS per week to the bill — minor — and closes a real gap in critical-alert reliability.

Pitfalls that turn SMS into expensive noise

Several failure modes come up repeatedly when UK teams adopt SMS alerts without enough discipline.

Flapping monitor. A single monitor that flips up-down every few minutes can send 100+ SMS per day. At 5p each, that is £5/day or £150/month. Always configure sensible retries (2-3) on any monitor attached to SMS notifications to filter transient blips.

Too many recipients. A broadcast SMS to the entire engineering team every time something goes wrong is expensive and ineffective — everyone assumes someone else is handling it. Pick one primary recipient per alert; use on-call rotations rather than broadcast.

SMS for non-critical monitors. Staging environment alerts via SMS are an expensive habit. Tighten the eligibility list quarterly: is each SMS-eligible monitor still actually critical?

Stale destination numbers. An engineer leaves the company but their phone number is still listed as an SMS destination. Alerts are delivered, but nobody reads them. Audit the SMS destination list on the same cadence as other access reviews.

No cost monitoring. SMS bills are often a line-item buried in a wider cloud invoice. Without explicit cost tracking at the SMS provider level, a runaway flapping monitor can rack up bills before anyone notices. Set spend alerts at the provider.

Trusting SMS alone. SMS delivery is reliable but not perfect. Phone carriers have outages; phones run out of battery; numbers get ported. Critical alerts should always be on at least two channels — typically SMS and email — so that a single-channel failure does not hide the outage.

Using shared work phones. A single on-call phone passed between team members on rotation sounds efficient in theory but tends to break in practice. The phone runs out of battery, gets left in a drawer, or is lost between handovers. Individual mobiles with configurable destination numbers are a more robust pattern.

Summary

SMS is the right tool for a narrow and important job — reaching the on-call engineer when a genuinely critical incident is happening and no other channel is guaranteed to break through. Configured with discipline, it is one of the most reliable pieces of the UK alerting toolkit. Configured loosely, it becomes a noisy monthly bill that everyone stops paying attention to.

Pick a provider that handles UK numbers well — Twilio and ClickSend are the usual defaults. Keep the list of SMS-eligible monitors short and reviewed. Pair SMS with another channel to insure against single-channel failures. Budget for SMS costs explicitly at the provider, and expect to see the bill tick up gradually if you relax the discipline. Done well, SMS earns its keep the first 3am weekend alert it delivers to a phone that would otherwise have been silent.

The broader truth is that SMS is a specialist tool. Getting the most out of it requires clarity about which alerts genuinely warrant it and operational discipline around retries, routing and rotation. Teams that invest that clarity up front use SMS for years with only small ongoing maintenance. Teams that treat SMS as just another channel end up with expensive noise and eventually turn it off.

Frequently asked questions