Daftar Isi
- Mengapa Uptime Kuma tidak bisa menelepon Anda sendiri
- Yang Anda butuhkan
- Langkah 1 — Buat saluran yang menelepon Anda
- Langkah 2 — Tambahkan Echobell sebagai notifikasi webhook
- Langkah 3 — Kirim payload yang bisa Anda saring
- Langkah 4 — Hentikan peringatan pemulihan agar tidak menelepon Anda
- Langkah 5 — Setel monitornya agar tidak jadi anak gembala pembohong
- Hanya berdering di luar jam kerja
- Berbagi peringatan dengan tim Anda
- Yang tidak Anda dapatkan dari setup ini
- Pemecahan masalah
- Pertanyaan yang sering diajukan
- Bisakah Uptime Kuma menelepon secara bawaan?
- Apakah ini berfungsi dengan Uptime Kuma swakelola di balik firewall?
- Apakah panggilannya akan menembus Jangan Ganggu?
- Bagaimana cara berhenti ditelepon saat layanannya pulih?
- Bisakah beberapa orang ditelepon untuk monitor yang sama?
- Penutup
- Terkait
Uptime Kuma mendukung lebih dari 90 penyedia notifikasi, tetapi tak satu pun membuat ponsel Anda berdering. Untuk mendapat panggilan telepon saat sebuah monitor mati, kirim notifikasi Webhook Uptime Kuma ke saluran Echobell yang disetel ke Panggilan. Panduan ini membahas custom body yang tepat, cara memisahkan peringatan gangguan dari peringatan pemulihan, serta dua kesalahan yang diam-diam merusak setup ini.
Uptime Kuma adalah monitor uptime swakelola paling populer yang ada — sekitar 90.000 bintang GitHub, dengan versi 2.5.0 yang dirilis pada Agustus 2026. Ia memeriksa endpoint HTTP, port TCP, catatan DNS, kontainer Docker, dan lainnya, dan ia benar-benar hebat dalam mendeteksi downtime.
Yang membuat Anda tetap rentan adalah bagian terakhirnya: menyampaikan peringatan itu ke manusia yang sedang tidur.
Mengapa Uptime Kuma tidak bisa menelepon Anda sendiri
Daftar notifikasi Uptime Kuma panjang — Telegram, Discord, Slack, email, Gotify, ntfy, dan puluhan lainnya — tetapi semuanya mengirimkan pesan. Pesan tunduk pada sakelar dering ponsel Anda, mode Jangan Ganggu, dan Mode Fokus iOS. Pada pukul 03.00 itu berarti peringatannya tiba dan tidak terjadi apa-apa.
Tidak ada penyedia bawaan "telepon ponsel saya". Pilihan yang biasanya diambil orang adalah:
- Twilio — Anda bisa membangun panggilan suara di atasnya, tetapi penyedia Twilio di Uptime Kuma mengirim SMS. Untuk suara, Anda perlu menulis layanan penghubung, membeli nomor, dan membayar per panggilan.
- PagerDuty, Zenduty, Spike.sh, Splunk On-Call — semuanya memang bisa menelepon, dan semuanya platform manajemen insiden lengkap dengan harga per pengguna yang sepadan. Pilihan tepat kalau Anda butuh rotasi dan kebijakan eskalasi; terlalu berat kalau Anda hanya butuh ponsel yang berdering.
- Gateway SMS — SMS tetap mendarat sebagai pesan, dan di iOS sebuah SMS tidak menembus Mode Fokus kecuali pengirimnya ada di daftar izin Anda.
Sebuah permintaan fitur untuk notifikasi panggilan VoIP sudah lama terbuka di repo Uptime Kuma. Sementara itu, penyedia Webhook generik adalah jalan keluarnya — ia bisa mengirim apa pun ke URL mana pun, dan itu sudah cukup.
Yang Anda butuhkan
- Instance Uptime Kuma yang berjalan (panduan ini ditulis untuk 2.x; custom body webhook-nya juga berfungsi di 1.23+)
- Echobell terpasang (App Store / Google Play)
- Waktu lima menit
Instance Uptime Kuma Anda perlu akses HTTPS keluar ke hook.echobell.one. Ia tidak perlu bisa dijangkau dari internet — ini webhook keluar, jadi monitor yang berjalan di server rumah atau di dalam jaringan privat pun berfungsi dengan baik.
Langkah 1 — Buat saluran yang menelepon Anda
Di Echobell, buat saluran bernama semisal Production Down. Setel jenis notifikasi langganannya ke Panggilan. Inilah pengaturan yang menentukan: peringatan Panggilan tiba sebagai layar panggilan masuk dan berdering menembus Mode Fokus iOS serta Jangan Ganggu, hal yang tidak bisa dilakukan notifikasi push.
Setel templatnya menjadi:
Title: 🔴 {{monitor}} is down
Body: {{message}}
Target: {{target}}
Lalu salin URL Webhook saluran itu. Bentuknya seperti:
https://hook.echobell.one/t/<channel-token>
Perlakukan URL itu sebagai rahasia — siapa pun yang memegangnya bisa membuat ponsel Anda berdering.
Langkah 2 — Tambahkan Echobell sebagai notifikasi webhook
Di Uptime Kuma, buka Settings → Notifications → Setup Notification lalu isi:
| Kolom | Nilai |
|---|---|
| Notification Type | Webhook |
| Friendly Name | Echobell — Down |
| Post URL | URL webhook Echobell Anda |
| Request Body | Custom Body |
Biarkan Additional Headers kosong.
Langkah 3 — Kirim payload yang bisa Anda saring
Inilah langkah yang dilewatkan sebagian besar panduan, dan inilah yang membedakan sistem peringatan dari mesin kebisingan.
Tempelkan ini ke Custom Body:
{
"monitor": "{{name}}",
"target": "{{hostnameOrURL}}",
"message": "{{ msg | strip_newlines }}",
"up": "{{ heartbeatJSON['status'] }}"
}
Uptime Kuma merender custom body dengan Liquid dan menyediakan variabel berikut:
| Variabel | Isinya |
|---|---|
{{name}} | Nama ramah milik monitor |
{{hostnameOrURL}} | Hostname atau URL yang diperiksa |
{{status}} | 🔴 Down, ✅ Up, atau ⚠️ Test |
{{msg}} | Alasan yang mudah dibaca manusia, misalnya connect ECONNREFUSED 10.0.0.4:443 |
{{ monitorJSON['...'] }} | Objek monitor selengkapnya |
{{ heartbeatJSON['...'] }} | Objek heartbeat selengkapnya |
Dua detail di payload itu memang disengaja:
strip_newlines pada msg. Pesan Uptime Kuma sering memuat pergantian baris, dan baris baru mentah di dalam string JSON membuat JSON-nya tidak valid. Tanpa filter itu, webhook Anda gagal sesekali — hanya untuk error yang teksnya kebetulan membungkus baris. Kalau Uptime Kuma Anda cukup baru sehingga punya filter json milik Liquid, "message": {{ msg | json }} (perhatikan: tanpa tanda kutip pengapit) bahkan lebih aman, karena ia juga meloloskan tanda kutip.
heartbeatJSON['status'] alih-alih {{status}}. Variabel status dirender sebagai teks emoji, yang canggung untuk dibandingkan. Status heartbeat berupa angka biasa:
0— down1— up2— pending3— maintenance
Memberinya tanda kutip ("up": "{{ ... }}") juga penting, dan Langkah 5 menjelaskan alasannya.
Langkah 4 — Hentikan peringatan pemulihan agar tidak menelepon Anda
Satu notifikasi Uptime Kuma menyala baik saat gangguan maupun saat pemulihan. Kalau dibiarkan, setup ini menelepon Anda ketika layanannya rusak lalu menelepon lagi ketika ia pulih sendiri. Panggilan kedua itulah yang mengajari orang untuk mengabaikan yang pertama.
Pisahkan keduanya memakai kondisi Echobell, yang dievaluasi sebelum apa pun dikirim:
Pada saluran Production Down (jenis notifikasi Panggilan), setel kondisinya menjadi:
up == "0"
Buat saluran kedua bernama Production Recovered, setel jenis notifikasinya ke Standar, lalu beri kondisi:
up == "1"
Dengan templat:
Title: ✅ {{monitor}} is back up
Body: {{message}}
Lalu tambahkan notifikasi webhook kedua di Uptime Kuma — custom body yang sama, monitor yang sama, tetapi mengarah ke URL saluran pemulihan. Kedua notifikasi menerima setiap peristiwa; masing-masing saluran membuang bagian yang tidak diurusnya.
Hasilnya: gangguan berdering, pemulihan tiba sebagai push senyap yang Anda baca saat pagi.
Langkah 5 — Setel monitornya agar tidak jadi anak gembala pembohong
Panggilan yang ternyata cuma gangguan jaringan dua detik lebih buruk daripada tidak ada panggilan sama sekali, karena panggilan berikutnya ikut diabaikan. Tiga pengaturan Uptime Kuma menangani sebagian besar urusan ini, semuanya ada pada monitornya sendiri:
- Retries — setel ke
2atau3. Uptime Kuma baru menandai monitor sebagai mati setelah sekian kali kegagalan berturut-turut, yang menyaring paket tunggal yang hilang. - Heartbeat Retry Interval — seberapa cepat ia memeriksa ulang selagi gagal. 20–30 detik adalah keseimbangan yang wajar; digabung dengan 3 kali percobaan ulang, Anda mendeteksi gangguan sungguhan dalam kira-kira satu menit.
- Resend Notification if Down X times consecutively — setel ke angka semisal
10, maka Uptime Kuma akan menelepon lagi kalau layanannya masih mati setelah sepuluh pemeriksaan berikutnya. Ini kebijakan eskalasi yang kasar, dan ia berfungsi.
Kalau Anda ingin panggilan yang tak terjawab terus dicoba segera alih-alih menunggu pengiriman ulang, aktifkan Retry Failed Call di pengaturan aplikasi Echobell.
Hanya berdering di luar jam kerja
Pada jam kerja Anda mungkin sudah menatap dashboard, dan ponsel yang berdering adalah gangguan yang tak Anda butuhkan. Variabel waktu sistem Echobell (semuanya UTC) memungkinkan satu saluran berperilaku berbeda menurut jam:
up == "0" && (hour >= 17 || hour < 9)
Kondisi itu hanya menelepon Anda di luar 09.00–17.00 UTC. Arahkan saluran kedua bertipe Standar ke kebalikannya untuk push di siang hari:
up == "0" && hour >= 9 && hour < 17
Ingat untuk menyesuaikan dengan zona waktu Anda sendiri — variabel ini selalu dihitung dalam UTC. Pembahasan yang lebih lengkap ada di notifikasi jendela waktu memakai kondisi UTC.
Berbagi peringatan dengan tim Anda
Saluran Echobell bisa dibagikan ke rekan tim lewat tautan langganan, dan setiap pelanggan memilih jenis notifikasinya sendiri. Jadi monitor yang sama bisa membuat ponsel insinyur on-call berdering sekaligus mendarat sebagai push biasa untuk yang lain — tanpa harga per pengguna, tanpa aturan perutean terpisah di Uptime Kuma.
Ini juga selaras dengan sikap privasi yang mendorong Anda menghosting sendiri sejak awal: monitor Anda tetap di infrastruktur Anda, dan Echobell menyimpan isi serta riwayat notifikasi di perangkat, bukan di servernya.
Yang tidak Anda dapatkan dari setup ini
Jujur soal batasannya akan menyelamatkan Anda dari migrasi yang buruk di kemudian hari. Echobell adalah lapisan pengiriman, bukan platform manajemen insiden. Ia tidak punya:
- Jadwal rotasi on-call atau serah terima lintas zona waktu
- Pohon eskalasi yang otomatis memanggil orang kedua
- Linimasa insiden, pelacakan tanda terima, atau perkakas postmortem
Kalau tim Anda membutuhkan semua itu, Anda butuh PagerDuty, Grafana Cloud IRM, atau sejenisnya. Yang ditutup setup ini adalah celah spesifik yang dibiarkan terbuka Uptime Kuma: mengubah gangguan yang terdeteksi menjadi ponsel yang benar-benar berdering. Bagi operator tunggal, tim kecil, dan homelab, biasanya itulah seluruh kebutuhannya.
Pemecahan masalah
Tombol Test tidak melakukan apa-apa. Ini wajar dengan payload di atas, dan selalu membingungkan orang saat pertama kali. Ketika Anda mengeklik Test, Uptime Kuma tidak punya heartbeat untuk dirender, jadi {{ heartbeatJSON['status'] }} menghasilkan string kosong dan tak satu pun kondisi cocok. Untuk menguji dengan benar, buat monitor TCP sekali pakai yang mengarah ke port yang tidak didengarkan siapa pun (127.0.0.1:9) lalu biarkan ia gagal.
Webhook gagal sesekali. Hampir selalu masalah baris baru — pastikan msg melewati strip_newlines. Ia hanya rusak untuk pesan error yang kebetulan memuat pergantian baris, itulah sebabnya kegagalannya tampak acak.
Echobell mengembalikan success: false dengan HTTP 200. Token salurannya salah atau salurannya sudah dihapus. Echobell menjawab 200 untuk token yang tidak dikenal tetapi panjangnya valid, jadi periksalah body JSON-nya, bukan kode statusnya.
HTTP 405. Saluran itu mengaktifkan POST Only dan ada yang mengirim GET. Uptime Kuma memakai POST, jadi ini biasanya berarti Anda menguji URL-nya di peramban.
Tidak ada dering, tetapi notifikasinya tiba. Jenis notifikasi langganannya Standar atau Peka Waktu, bukan Panggilan. Jenis notifikasi dipilih per pelanggan, jadi periksalah di perangkat yang tidak berdering.
Pertanyaan yang sering diajukan
Bisakah Uptime Kuma menelepon secara bawaan?
Tidak. Uptime Kuma punya lebih dari 90 penyedia notifikasi, tetapi semuanya mengirimkan pesan. Panggilan telepon mengharuskan Anda mengarahkan sebuah webhook ke layanan yang bisa melakukan panggilan, seperti Echobell, atau memakai platform manajemen insiden berbayar.
Apakah ini berfungsi dengan Uptime Kuma swakelola di balik firewall?
Ya. Webhook-nya adalah permintaan HTTPS keluar dari instance Uptime Kuma Anda, jadi ia hanya perlu menjangkau hook.echobell.one. Instance Anda tidak perlu punya alamat publik.
Apakah panggilannya akan menembus Jangan Ganggu?
Ya. Jenis notifikasi Panggilan Echobell tampil sebagai panggilan masuk, yang berdering menembus Mode Fokus iOS dan Jangan Ganggu. Lihat menembus Mode Fokus iOS untuk peringatan kritis untuk detail dan pengaturan yang terlibat.
Bagaimana cara berhenti ditelepon saat layanannya pulih?
Gunakan dua saluran dengan kondisi — up == "0" untuk saluran panggilan dan up == "1" untuk saluran pemulihan berprioritas standar — lalu arahkan satu notifikasi webhook ke masing-masing. Langkah 4 di atas menjelaskannya.
Bisakah beberapa orang ditelepon untuk monitor yang sama?
Bisa. Bagikan salurannya ke rekan tim Anda dan setiap pelanggan memilih jenis notifikasinya sendiri. Semua yang berlangganan saluran panggilan akan ditelepon.
Penutup
Setup ini terdiri dari satu webhook, satu custom body, dan dua kondisi. Ia membiarkan monitor, logika percobaan ulang, dan halaman status Uptime Kuma Anda persis seperti semula, dan ia menutup jarak antara "monitornya sudah tahu" dan "manusianya sudah tahu".
Unduh Echobell untuk iPhone atau dapatkan di Google Play, lalu hubungkan dulu satu monitor yang tidak kritis dan gagalkan dengan sengaja. Percayai jalurnya sebelum Anda mengandalkannya.