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.
Ping is the oldest and simplest health check on the internet: send a small packet, wait for the echo. It answers one question very well - "can I reach this host?" - and says nothing about whether the services on it work. Knowing both halves of that sentence is the key to using ping monitoring well.
noc724 checks your websites, servers and APIs around the clock and alerts you by SMS, Telegram or Bale the moment something breaks.
ping sends an ICMP echo request to an IP address. If the host is reachable and allowed to answer, it sends back an echo reply. The tool reports the round-trip time for each packet and, at the end, how many were lost:
ping -c 4 203.0.113.10
64 bytes from 203.0.113.10: icmp_seq=1 ttl=56 time=18.4 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=56 time=18.9 ms
64 bytes from 203.0.113.10: icmp_seq=3 ttl=56 time=17.8 ms
64 bytes from 203.0.113.10: icmp_seq=4 ttl=56 time=19.2 ms
4 packets transmitted, 4 received, 0% packet lossA ping monitor does the same thing on a schedule, from outside your network, and alerts when replies stop.
The time a packet takes to reach the host and come back. Absolute values depend on distance: a few milliseconds inside a city, tens of milliseconds across a country, more across continents. What matters for monitoring is the trend - a host that normally answers in 20 ms and suddenly takes 200 ms is telling you something.
The share of requests that got no reply. Occasional single losses are normal on the internet. Sustained loss of a few percent makes TCP connections slow (they retransmit), and heavy loss makes them fail.
The variation between consecutive round-trip times. High jitter barely matters for web pages but ruins voice and video calls.
Before alerting on a silent host, rule out the usual suspects:
If ICMP is blocked on purpose, use a TCP port check on a port that is open instead.
A server can be perfectly pingable while:
500 errors,Ping lives in the operating system's network stack, so it keeps answering as long as the kernel runs. That makes it a good reachability signal and a poor service signal. Layer your checks:
| Layer | Check | Detects |
|---|---|---|
| Network | Ping | Host or route unreachable |
| Transport | Port (TCP/UDP) | Service not listening |
| Application | HTTP / keyword / API | Service broken or returning errors |
When everything fails at once, the lowest failing layer usually points at the cause.
It depends on distance. Under 30 ms is typical within one country, 100-200 ms between continents. Compare a host with its own history rather than with a universal number.
Brief spikes are normal. Loss that stays above 1-2% for minutes usually means congestion or a faulty link and is worth investigating.
No. Ping only proves the host is reachable. Use HTTP or keyword checks to know the website actually works.
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.