SMS, Telegram or Bale? Choosing Alert Channels Without Alert Fatigue
Which downtime alerts should go by SMS and which to Telegram or Bale, how to route by urgency, and how to keep the important alerts from drowning in noise.
Uptime is the share of time a website, server or service is available and working. It is usually written as a percentage over a period - for example 99.9% uptime in a month. Downtime is the opposite: the time it can't be reached or doesn't work properly.
Small differences in the percentage add up to very different amounts of downtime. This is how much downtime each common uptime level allows:
| Uptime | Downtime per month | Downtime per year |
|---|---|---|
| 99% | about 7 hours 18 minutes | about 3 days 15 hours |
| 99.5% | about 3 hours 39 minutes | about 1 day 20 hours |
| 99.9% | about 43 minutes | about 8 hours 46 minutes |
| 99.95% | about 22 minutes | about 4 hours 23 minutes |
| 99.99% | about 4 minutes | about 53 minutes |
Your hosting provider's own figure only covers its servers. To know what your visitors actually experience, use an external uptime monitoring service that checks your site every few minutes from outside your network, records every failure and alerts you immediately. noc724 does this for websites, APIs, servers (ping and ports), cron jobs, DNS, SSL and domains, and sends alerts by SMS, Telegram and Bale.
In practice no: maintenance, network problems and failures happen. Good services aim for 99.9% or higher and react fast when something breaks.
They are often used interchangeably. Strictly, uptime is the time a system is running, while availability is the time it is actually usable by users.
Every 5 minutes is enough for most sites; business-critical services are usually checked every minute or more often.
noc724 checks your websites, servers and APIs around the clock and alerts you by SMS, Telegram or Bale the moment something breaks.
Written by
The noc724 team
Uptime monitoring engineers
We build and run noc724, an uptime monitoring service that checks websites, servers and APIs from several cities in Iran. These guides come from the problems we and our users run into while keeping services online.
Contact the teamExpert on:Monitoring
Which downtime alerts should go by SMS and which to Telegram or Bale, how to route by urgency, and how to keep the important alerts from drowning in noise.
Why uptime monitors raise false alarms - network blips, timeouts, rate limits, content changes - and the settings that remove them while keeping real alerts fast.
How to set up a simple on-call rotation and escalation policy so every critical alert is answered, without burning out a small team.