Ada satu kategori pertanyaan monitoring yang sengaja dijawab buruk oleh Grafana dan Prometheus: apakah situs saya up, dilihat dari luar, saat ini juga, dan apakah ada yang menerima page soal itu? Stack observability internal saya — Prometheus men-scrape node exporter, Loki mengumpulkan log, dashboard Grafana — melihat semua hal di dalam server. Tapi saat sebuah aturan firewall yang salah konfigurasi memblokir port 443 di satu VPS tahun lalu, semua metrik internal tetap hijau. Hari itu para user-lah yang menjadi sistem monitoring, dan persis mode kegagalan itulah alasan external uptime check ada.
Uptime Kuma adalah jawaban saya untuk lapisan itu. Ia adalah uptime monitor self-hosted karya Louis Lam — 88 ribu bintang GitHub dan pengembangan yang sangat aktif per pertengahan 2026 — yang berjalan sebagai satu container Docker dan menggantikan tagihan rutin layanan uptime hosted untuk fleet kecil. Satu container, satu file SQLite, UI reaktif yang bersih, dan notifikasi ke hampir apa saja. Berikut cara saya menjalankannya, posisinya di samping stack Prometheus, dan jebakan yang penting di production.
Kenapa Repot Self-Host Monitoring Uptime
Layanan hosted seperti berbagai produk SaaS pinger memang oke sampai Anda menabrak dinding free tier mereka: interval check dalam hitungan menit, jumlah monitor terbatas, status page dan alert SMS di balik paywall. Untuk agency atau developer yang menjalankan sepuluh sampai lima puluh endpoint di beberapa VPS, hitung-hitungannya cepat berpihak ke self-hosting:
- Monitor tanpa batas dengan interval sesuka Anda — saya menjalankan check 20 detik di endpoint kritis pendapatan dan 5 menit di ekor panjang, semuanya di container yang idle di bawah 200 MB RAM.
- Lebih dari 90 provider notifikasi bawaan: Telegram, Discord, Slack, SMTP, Gotify, webhook. Alert saya mendarat di Telegram dalam grup yang sama dengan alert Grafana, jadi kebiasaan on-call tidak berubah.
- Status page sudah termasuk, bisa dipetakan ke custom domain — fitur yang paling konsisten disembunyikan layanan hosted di balik tier berbayar.
Posisinya penting: Uptime Kuma adalah check dari-luar-ke-dalam, Prometheus adalah kebenaran dari-dalam-ke-luar. Kuma memberi tahu saya user tidak bisa mencapai API; Prometheus memberi tahu kenapa. Jalankan keduanya — mereka menjawab pertanyaan berbeda, dan satu insiden VPS-down di mana Kuma mem-page saya sebelum alert internal mana pun menyala sudah membayar waktu setup-nya berkali-kali lipat.
Setup: Satu Container, Dua Header, Selesai
Seluruh instalasi untuk lini versi 2 hanyalah ini:
docker run -d --restart=unless-stopped \
-p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma \
louislam/uptime-kuma:2Satu-satunya bagian yang tidak obvious adalah reverse proxy. UI Uptime Kuma berjalan di atas WebSocket, jadi proxy_pass polos hanya menampilkan spinner loading selamanya. Header Upgrade dan Connection itu wajib:
# nginx vhost — Uptime Kuma talks WebSocket,
# so the Upgrade/Connection headers are mandatory
server {
server_name status-admin.example.com;
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}Tipe Monitor yang Benar-Benar Saya Pakai
Kuma mendukung HTTP(s), TCP, ping, DNS, pencocokan keyword dan JSON-query, WebSocket, container Docker, dan push monitor. Empat di antaranya mencakup 95 persen kebutuhan nyata saya:
| Tipe monitor | Apa yang diverifikasi | Di mana saya memakainya |
|---|---|---|
| HTTP(s) keyword | Endpoint mengembalikan 2xx DAN body mengandung string pilihan Anda. Menangkap white-screen-of-death yang oleh status check polos disebut sehat. | Situs marketing dan halaman login ERP — saya mencocokkan string footer yang hanya ter-render saat aplikasi boot sempurna. |
| TCP port | Sebuah port menerima koneksi. Tanpa pemahaman protokol, murni keterjangkauan. | PostgreSQL dan Redis di interface privatnya, relay SMTP di 587. |
| Push (heartbeat) | Membalik arah: job Anda harus memanggil URL Kuma setiap N detik atau monitornya dianggap down. Dead-man switch yang sangat sederhana. | Backup restic malam hari dan job ETL cron — backup yang diam-diam berhenti jalan lebih buruk daripada server yang crash dengan berisik. |
| DNS record | Sebuah nama me-resolve ke record yang diharapkan di resolver pilihan Anda. | Menangkap domain kedaluwarsa dan migrasi DNS yang kacau sebelum pelanggan menyadarinya. |
Alerting Tanpa False Page Jam 3 Pagi
Setiap monitor mendapat jumlah retry sebelum berubah jadi down — saya pakai tiga retry pada interval normal, yang menyaring blip satu-paket yang kalau tidak akan menghasilkan alert fatigue. Notifikasi menempel per monitor atau sebagai default, dan masing-masing menyala saat down maupun recovery, jadi thread Telegram terbaca seperti timeline insiden yang rapi.
Satu pola yang layak ditiru: arahkan grup monitor berbeda ke kanal berbeda. Endpoint kritis pendapatan mem-page ponsel saya via Telegram; ekor panjang tool internal masuk ke kanal sunyi yang saya pindai tiap pagi. Kuma membuat ini sepele karena binding notifikasi per monitor, bukan global.
Pro tip: monitor monitor Anda. Saya menjalankan push check Kuma yang menunjuk ke heartbeat dari VPS yang menampung Kuma itu sendiri, dikonfigurasi arah sebaliknya di instance kedua di rumah pada Raspberry Pi. Dua penjaga murah yang saling mengawasi mengalahkan satu penjaga sempurna yang Anda lupa juga bisa mati.
Status Page yang Benar-Benar Bisa Dilihat Klien
Kuma membawa beberapa status page langsung dari kotaknya, masing-masing dengan pilihan monitor, branding, dan custom domain opsional sendiri. Untuk kerja klien ini diam-diam salah satu fitur bernilai tertinggi: halaman status.domain-klien.com memakan waktu sepuluh menit, tampak profesional, dan mengubah dinamika support — klien mengecek halaman alih-alih mengirim pesan ke saya saat ada yang terasa lambat.
Status page juga mendukung banner insiden yang Anda pasang manual. Banner dua baris sudah-diketahui-dan-sedang-ditangani membeli goodwill yang luar biasa saat downtime, dan menulisnya dari Kuma jauh lebih enak daripada menyusun email permintaan maaf dari nol.
Jebakan Production yang Layak Diketahui
- SQLite berarti aturan filesystem: volume data harus mendukung POSIX file lock. Volume berbasis NFS merusak database — simpan /app/data di disk lokal, titik.
- Single-node memang by design. Kuma tidak punya clustering; kalau host-nya mati, monitoring ikut mati. Itu tidak masalah untuk peran penjaga selama ada yang mengawasi si penjaga (lihat pro tip di atas).
- Lakukan check dari tempat user Anda berada. Instance Kuma di datacenter yang sama dengan layanan yang dicheck akan melewatkan seluruh kelas kegagalan jaringan. Punya saya berjalan di region berbeda dari workload yang diawasinya.
- Backup volumenya. Definisi monitor, konfigurasi notifikasi, dan riwayat uptime semuanya hidup di file SQLite itu — menambahkannya satu baris di job restic, tapi satu sore yang menyakitkan kalau harus dibangun ulang dari ingatan.
Jangan mengekspos UI admin ke internet publik hanya karena status page harus publik. Taruh hostname admin di belakang VPN atau allowlist Anda, dan biarkan hanya domain status page yang menghadap dunia. Pemisahan ini lima menit saja di reverse proxy mana pun.
Dari Nol ke Termonitor dalam 30 Menit
- Jalankan perintah Docker di atas pada VPS di region atau provider berbeda dari workload utama Anda, dan buat akun admin segera — pengunjung pertama yang menang.
- Taruh di belakang reverse proxy dengan header WebSocket, UI admin di hostname privat, HTTPS lewat setup certbot atau Caddy Anda yang biasa.
- Tambahkan monitor HTTP keyword untuk setiap endpoint publik, monitor TCP untuk database, dan push monitor untuk setiap job terjadwal yang kegagalannya tidak akan Anda sadari.
- Sambungkan notifikasi: satu kanal nyaring untuk paging, satu kanal sunyi untuk ekor panjang. Set tiga retry sebelum down supaya blip tidak masuk ke keduanya.
- Terbitkan satu status page per audiens, tambahkan volume data Kuma ke job backup Anda, dan jadwalkan tes kuartalan di mana Anda sengaja mematikan satu service dan menghitung waktu sampai page datang.
Intinya
Uptime Kuma menempati sweet spot yang kebanyakan dilewati pasar monitoring: cukup serius untuk fleet production, cukup sederhana sehingga seluruh mental model-nya adalah satu container dan satu file SQLite. Ia tidak akan menggantikan Prometheus untuk urusan internal dan memang tidak seharusnya — tapi sebagai lapisan luar-ke-dalam yang mem-page Anda saat user terkunci di luar, ia mengerjakan tugas layanan berbayar di hardware yang sudah Anda sewa. Untuk tim kecil yang menjalankan infrastruktur sendiri, ini kira-kira tiga puluh menit setup dengan leverage tertinggi yang bisa saya rekomendasikan.
Sumber dan bacaan lanjutan