Alerty telefoniczne z Uptime Kuma: spraw, by telefon zadzwonił

Spis treści

• Dlaczego Uptime Kuma sam nie zadzwoni na Twój telefon
• Czego potrzebujesz
• Krok 1 — utwórz kanał, który do Ciebie zadzwoni
• Krok 2 — dodaj Echobell jako powiadomienie webhook
• Krok 3 — wyślij payload, który da się filtrować
• Krok 4 — spraw, by alerty o powrocie do normy nie dzwoniły
• Krok 5 — dostrój monitor, żeby nie wywoływał fałszywych alarmów
• Dzwoń tylko poza godzinami pracy
• Udostępnianie alertu zespołowi
• Czego ta konfiguracja nie daje
• Rozwiązywanie problemów
• Najczęściej zadawane pytania
• Czy Uptime Kuma potrafi sam zadzwonić na telefon?
• Czy zadziała to z samodzielnie hostowanym Uptime Kuma za firewallem?
• Czy połączenie telefoniczne ominie tryb Nie przeszkadzać?
• Jak przestać odbierać telefony przy powrocie usługi do działania?
• Czy przy jednym monitorze można dzwonić do kilku osób?
• Podsumowanie
• Powiązane materiały

Uptime Kuma obsługuje ponad 90 dostawców powiadomień, ale żaden z nich nie sprawi, że Twój telefon zadzwoni. Aby dostać połączenie, gdy monitor wykryje awarię, skieruj powiadomienie typu Webhook z Uptime Kuma do kanału Echobell ustawionego na połączenie. Ten przewodnik pokazuje dokładną treść własnego payloadu, sposób rozdzielenia alertów o awarii od alertów o powrocie do normy oraz dwa błędy, które po cichu psują całą konfigurację.

Uptime Kuma to najpopularniejszy samodzielnie hostowany monitor dostępności — mniej więcej 90 000 gwiazdek na GitHubie, a wersja 2.5.0 pojawiła się w sierpniu 2026. Sprawdza endpointy HTTP, porty TCP, rekordy DNS, kontenery Dockera i wiele więcej, a w wykrywaniu awarii jest naprawdę znakomity.

Zostawia Cię za to bez ochrony na ostatnim odcinku: przy dostarczeniu alertu do śpiącego człowieka.

Dlaczego Uptime Kuma sam nie zadzwoni na Twój telefon

Lista powiadomień w Uptime Kuma jest długa — Telegram, Discord, Slack, e-mail, Gotify, ntfy i dziesiątki innych — ale każde z nich dostarcza wiadomość. Wiadomości podlegają przełącznikowi dzwonka w telefonie, trybowi Nie przeszkadzać i trybom Skupienia w iOS. O 3:00 nad ranem oznacza to, że alert przychodzi i nic się nie dzieje.

Nie ma tu wbudowanego dostawcy „zadzwoń na mój telefon”. Rozwiązania, na które zwykle wpadają użytkownicy, to:

• Twilio — da się na nim zbudować połączenia głosowe, ale dostawca Twilio w Uptime Kuma wysyła SMS-y. Głos oznacza napisanie usługi pośredniczącej, wykupienie numeru i płacenie za każde połączenie.
• PagerDuty, Zenduty, Spike.sh, Splunk On-Call — te faktycznie dzwonią, ale są pełnymi platformami do zarządzania incydentami, z odpowiadającym temu cennikiem za użytkownika. Właściwy wybór, jeśli potrzebujesz grafików dyżurów i polityk eskalacji; przerost formy, jeśli chcesz tylko, żeby telefon zadzwonił.
• Bramki SMS — SMS i tak przychodzi jako wiadomość, a w iOS nie przebija się przez tryb Skupienia, o ile nadawca nie jest na liście dozwolonych.

Zgłoszenie o powiadomienia głosowe VoIP wisi w repozytorium Uptime Kuma już od dłuższego czasu. Tymczasem furtką pozostaje uniwersalny dostawca Webhook — potrafi wysłać dowolne dane pod dowolny adres URL, a to wszystko, czego potrzeba.

Czego potrzebujesz

• Działającej instancji Uptime Kuma (ten przewodnik powstał dla wersji 2.x; własna treść webhooka działa też w 1.23+)
• Zainstalowanego Echobell (App Store / Google Play)
• Pięciu minut

Twoja instancja Uptime Kuma musi mieć wychodzące połączenie HTTPS do hook.echobell.one. Nie musi być osiągalna z internetu — to webhook wychodzący, więc monitor działający na domowym serwerze albo w sieci prywatnej sprawdzi się bez problemu.

Krok 1 — utwórz kanał, który do Ciebie zadzwoni

W Echobell utwórz kanał o nazwie w rodzaju Production Down. Ustaw typ powiadomień jego subskrypcji na połączenie. To ustawienie ma tu kluczowe znaczenie: alerty typu połączenie pojawiają się jako ekran rozmowy przychodzącej i dzwonią mimo trybu Skupienia i Nie przeszkadzać w iOS, czego powiadomienie push nie potrafi.

Ustaw takie szablony:

Title: 🔴 {{monitor}} is down
Body: {{message}}
Target: {{target}}

Następnie skopiuj adres URL webhooka kanału. Wygląda tak:

https://hook.echobell.one/t/<channel-token>

Traktuj ten adres jak sekret — każdy, kto go ma, może sprawić, że Twój telefon zadzwoni.

Krok 2 — dodaj Echobell jako powiadomienie webhook

W Uptime Kuma przejdź do Settings → Notifications → Setup Notification i uzupełnij:

Pole Additional Headers zostaw puste.

Krok 3 — wyślij payload, który da się filtrować

Ten krok większość poradników pomija, a to on decyduje o różnicy między systemem alertów a maszyną do robienia hałasu.

Wklej to w polu Custom Body:

{
  "monitor": "{{name}}",
  "target": "{{hostnameOrURL}}",
  "message": "{{ msg | strip_newlines }}",
  "up": "{{ heartbeatJSON['status'] }}"
}

Uptime Kuma renderuje własne treści przy użyciu Liquid i udostępnia następujące zmienne:

Dwa szczegóły w tym payloadzie są celowe:

Filtr strip_newlines na msg. Komunikat z Uptime Kuma często zawiera znaki końca wiersza, a surowy znak nowej linii wewnątrz ciągu JSON to niepoprawny JSON. Bez tego filtra webhook zawodzi z pozoru losowo — tylko przy tych błędach, których tekst akurat się łamie. Jeśli Twoja wersja Uptime Kuma ma już filtr json z Liquid, jeszcze bezpieczniejsze jest "message": {{ msg | json }} (uwaga: bez otaczających cudzysłowów), bo escapuje również cudzysłowy.

heartbeatJSON['status'] zamiast {{status}}. Zmienna status renderuje się jako tekst z emoji, który niewygodnie się porównuje. Status heartbeatu to zwykła liczba:

• 0 — awaria
• 1 — działa
• 2 — oczekiwanie
• 3 — prace serwisowe

Ujęcie jej w cudzysłowy ("up": "{{ ... }}") też ma znaczenie, a dlaczego — wyjaśnia krok 5.

Krok 4 — spraw, by alerty o powrocie do normy nie dzwoniły

Pojedyncze powiadomienie w Uptime Kuma uruchamia się zarówno przy awarii, jak i przy powrocie usługi. Zostawione samo sobie zadzwoni, gdy usługa padnie, a potem zadzwoni ponownie, gdy sama się podniesie. To ten drugi telefon uczy ludzi ignorować pierwszy.

Rozdziel je za pomocą warunków w Echobell, które są sprawdzane przed dostarczeniem czegokolwiek:

W kanale Production Down (typ powiadomień połączenie) ustaw warunek:

up == "0"

Utwórz drugi kanał o nazwie Production Recovered, ustaw jego typ powiadomień na standardowy i nadaj mu warunek:

up == "1"

Z szablonami:

Title: ✅ {{monitor}} is back up
Body: {{message}}

Następnie dodaj w Uptime Kuma drugie powiadomienie webhook — z tą samą własną treścią i tymi samymi monitorami, ale wskazujące na adres URL kanału powrotu do normy. Oba powiadomienia dostają wszystkie zdarzenia; każdy kanał odrzuca tę połowę, która go nie interesuje.

Efekt: awaria dzwoni, a powrót do normy przychodzi jako ciche powiadomienie push do przeczytania rano.

Krok 5 — dostrój monitor, żeby nie wywoływał fałszywych alarmów

Telefon, który okazuje się dwusekundowym zakłóceniem sieci, jest gorszy niż brak telefonu, bo następny też zostanie zignorowany. Najwięcej robią tu trzy ustawienia Uptime Kuma, wszystkie na poziomie monitora:

• Retries — ustaw na 2 lub 3. Uptime Kuma oznaczy monitor jako niedziałający dopiero po tylu kolejnych niepowodzeniach, co odsiewa pojedyncze zgubione pakiety.
• Heartbeat Retry Interval — jak szybko ponawia sprawdzenie w trakcie awarii. 20–30 sekund to rozsądny kompromis; w połączeniu z 3 próbami wykryjesz prawdziwą awarię w mniej więcej minutę.
• Resend Notification if Down X times consecutively — ustaw wartość rzędu 10, a Uptime Kuma zadzwoni ponownie, jeśli usługa nadal nie działa po kolejnych dziesięciu sprawdzeniach. To prymitywna polityka eskalacji, ale działa.

Jeśli chcesz, aby nieodebrane połączenie było od razu ponawiane, zamiast czekać na powtórne powiadomienie, włącz ponawianie nieudanych połączeń w ustawieniach aplikacji Echobell.

Dzwoń tylko poza godzinami pracy

W ciągu dnia pewnie i tak patrzysz w dashboard, a dzwoniący telefon to niepotrzebne przerwanie pracy. Zmienne czasu systemowego w Echobell (wszystkie w UTC) pozwalają jednemu kanałowi zachowywać się różnie w zależności od godziny:

up == "0" && (hour >= 17 || hour < 9)

Ten warunek dzwoni tylko poza przedziałem 09:00–17:00 UTC. Drugi kanał typu standardowego ustaw na warunek odwrotny, aby w dzień dostawać powiadomienia push:

up == "0" && hour >= 9 && hour < 17

Pamiętaj o przesunięciu względem własnej strefy czasowej — te zmienne zawsze liczone są w UTC. Szerzej opisuje to tekst o powiadomieniach w oknach czasowych z warunkami UTC.

Udostępnianie alertu zespołowi

Kanał Echobell można udostępnić współpracownikom linkiem subskrypcji, a każda subskrybująca osoba wybiera własny typ powiadomień. Ten sam monitor może więc dzwonić na telefon osoby na dyżurze, a wszystkim pozostałym trafiać jako zwykły push — bez opłat za użytkownika i bez osobnych reguł routingu w Uptime Kuma.

Dobrze współgra to też z samym podejściem do prywatności, które stoi za self-hostingiem: Twoje monitory zostają na Twojej infrastrukturze, a Echobell trzyma treść i historię powiadomień na urządzeniu, a nie na swoich serwerach.

Czego ta konfiguracja nie daje

Uczciwe wyznaczenie granicy oszczędzi Ci później nieudanej migracji. Echobell jest warstwą dostarczania, a nie platformą do zarządzania incydentami. Nie ma:

• Grafików dyżurów ani przekazywania zmian między strefami czasowymi
• Drzew eskalacji, które automatycznie wzywają kolejną osobę
• Osi czasu incydentów, śledzenia potwierdzeń ani narzędzi do analiz powypadkowych

Jeśli Twój zespół tego potrzebuje, sięgnij po PagerDuty, Grafana Cloud IRM lub podobne rozwiązanie. Ta konfiguracja zamyka za to konkretną lukę, którą zostawia Uptime Kuma: zamianę wykrytej awarii w telefon, który naprawdę dzwoni. W przypadku osób pracujących samodzielnie, małych zespołów i domowych laboratoriów zwykle na tym kończą się wymagania.

Rozwiązywanie problemów

Przycisk Test nic nie robi. Przy powyższym payloadzie to normalne i za pierwszym razem myli każdego. Po kliknięciu Test Uptime Kuma nie ma żadnego heartbeatu do wyrenderowania, więc {{ heartbeatJSON['status'] }} zamienia się w pusty ciąg i żaden warunek nie jest spełniony. Aby przetestować poprawnie, utwórz jednorazowy monitor TCP wskazujący na port, na którym nic nie nasłuchuje (127.0.0.1:9), i pozwól mu zawieść.

Webhook zawodzi z pozoru losowo. Niemal zawsze chodzi o znaki nowej linii — sprawdź, czy msg przechodzi przez strip_newlines. Psuje się tylko przy komunikatach błędów zawierających łamanie wiersza, dlatego wygląda to na przypadek.

Echobell zwraca success: false przy kodzie HTTP 200. Token kanału jest niepoprawny albo kanał został usunięty. Echobell odpowiada kodem 200 na nieznany token o poprawnej długości, więc sprawdzaj treść JSON, a nie kod statusu.

HTTP 405. Kanał ma włączoną opcję POST Only, a coś wysłało żądanie GET. Uptime Kuma wysyła POST, więc zwykle oznacza to, że testowano adres URL w przeglądarce.

Nic nie dzwoni, choć powiadomienie przychodzi. Typ powiadomień w subskrypcji jest ustawiony na standardowy albo czasowo krytyczny zamiast na połączenie. Typ powiadomień wybiera każdy subskrybent osobno, więc sprawdź go na urządzeniu, które nie dzwoni.

Najczęściej zadawane pytania

Czy Uptime Kuma potrafi sam zadzwonić na telefon?

Nie. Uptime Kuma ma ponad 90 dostawców powiadomień, ale wszyscy dostarczają wiadomości. Połączenia telefoniczne wymagają skierowania webhooka do usługi, która potrafi je wykonać — takiej jak Echobell — albo skorzystania z płatnej platformy do zarządzania incydentami.

Czy zadziała to z samodzielnie hostowanym Uptime Kuma za firewallem?

Tak. Webhook to wychodzące żądanie HTTPS z Twojej instancji Uptime Kuma, więc musi ona jedynie dosięgnąć hook.echobell.one. Instancja nie potrzebuje publicznego adresu.

Czy połączenie telefoniczne ominie tryb Nie przeszkadzać?

Tak. Typ powiadomień „połączenie” w Echobell prezentuje się jak rozmowa przychodząca, więc dzwoni mimo trybu Skupienia i Nie przeszkadzać w iOS. Szczegóły i potrzebne ustawienia opisuje tekst o omijaniu trybu Skupienia w iOS przy krytycznych alertach.

Jak przestać odbierać telefony przy powrocie usługi do działania?

Skorzystaj z dwóch kanałów z warunkami — up == "0" dla kanału dzwoniącego i up == "1" dla kanału o standardowym priorytecie — i skieruj po jednym powiadomieniu webhook na każdy z nich. Krok 4 powyżej opisuje to po kolei.

Czy przy jednym monitorze można dzwonić do kilku osób?

Tak. Udostępnij kanał współpracownikom, a każda subskrybująca osoba wybierze własny typ powiadomień. Zadzwoni do wszystkich, którzy subskrybują kanał dzwoniący.

Podsumowanie

Cała konfiguracja to jeden webhook, jedna własna treść żądania i dwa warunki. Twoje monitory w Uptime Kuma, logika ponawiania i strony statusu zostają dokładnie takie, jakie były, a luka między „monitor zauważył” a „człowiek zauważył” znika.

Pobierz Echobell na iPhone’a albo zainstaluj z Google Play, a potem podepnij najpierw jeden mniej istotny monitor i celowo doprowadź do jego awarii. Zaufaj tej ścieżce, zanim na niej polegniesz.

---

Powiązane materiały

• Dokumentacja integracji z Uptime Kuma
• Opis warunków kanału
• Alerty z Upptime w Echobell
• Alerty telefoniczne, gdy Twoje API przestaje działać
• Przewodnik dla programistów: jak wyleczyć zmęczenie alertami