Uptime Kuma adalah tool ringan untuk memantau apakah website, API, dan layanan lain bisa diakses dari luar. Instalasinya cepat, cukup satu container. Yang sering salah justru tempat memasangnya. Kalau Uptime Kuma dijalankan di server yang sama dengan aplikasi yang dipantau, saat server itu mati, aplikasi dan monitoring-nya ikut mati bersamaan, dan tidak ada yang mengirim notifikasi.
Apa yang Dikerjakan Uptime Kuma, dan Apa yang Tidak
Uptime Kuma mengecek layanan dari sisi luar secara terjadwal. Tool ini mencatat response time dan uptime, mengirim notifikasi kalau pengecekan gagal, dan menyediakan status page. Karena self-hosted dan ringan, Uptime Kuma praktis untuk tim development atau operations yang ingin mengelola monitoring sendiri tanpa biaya langganan.
Uptime Kuma tidak menggantikan monitoring server. Tool ini tidak melihat CPU, memori, disk, atau tren kapasitas jangka panjang. Pembagian yang praktis: Zabbix atau tool sejenis untuk memantau resource dan kapasitas server, Uptime Kuma untuk mengecek layanan dari luar sekaligus mengirim notifikasi dan menampilkan status ke pengguna.
Pasang di Luar Sistem yang Dipantau
Kalau Uptime Kuma berbagi server, hypervisor, jaringan, atau region cloud dengan aplikasinya, keduanya bisa kena gangguan yang sama. Saat aplikasi tidak bisa diakses, dashboard dan jalur notifikasinya juga ikut hilang.
Untuk layanan publik, pakai VPS kecil di provider lain, atau minimal di region yang berbeda. Layanan internal yang tidak bisa diakses dari internet mungkin butuh instance kedua di dalam jaringan kantor. Untuk layanan yang dipakai pelanggan, tetap usahakan ada pengecekan dari luar jaringan internal.
Cara mengetesnya gampang: matikan server aplikasi di jadwal maintenance, lalu lihat apakah notifikasi tetap sampai ke HP tim. Kalau tidak sampai, berarti monitoring-nya ikut tumbang bersama aplikasi.
Pilih Jenis Monitor Sesuai Layanannya
Uptime Kuma punya beberapa jenis monitor, dan pilihannya tergantung bagaimana layanan itu bisa gagal. HTTP check biasa, misalnya, tidak akan menangkap aplikasi yang menampilkan halaman error tapi tetap mengembalikan status 200.
| Jenis monitor | Dipakai untuk | Catatan |
|---|---|---|
| HTTP(s) | Endpoint publik yang status code-nya bisa dipercaya | Pastikan aplikasi memang mengembalikan status error saat gagal sebelum hanya mengandalkan jenis ini |
| HTTP(s) Keyword | Halaman dan API yang bisa gagal tapi tetap mengembalikan 200 | Cari teks yang hanya muncul kalau halaman tampil dengan benar. Teks dari header atau footer tidak cocok |
| HTTP(s) Json Query | Health endpoint yang mengembalikan status dalam format JSON | Berguna kalau endpoint juga melaporkan dependency yang sedang bermasalah, selain status hidup atau mati |
| TCP Port | Layanan non-HTTP seperti mail, database, atau message broker | Hanya membuktikan port menerima koneksi. Pengecekan di level protokol lebih meyakinkan |
| Ping | Cek dasar apakah host bisa dijangkau | ICMP sering difilter atau diprioritaskan rendah, jadi anggap sebagai data pendukung |
| DNS | Resolusi domain dan kebenaran record | Menangkap masalah registrar, propagasi, atau penyedia DNS yang kalau lewat pengecekan endpoint hanya terlihat sebagai gagal biasa |
| Push | Cron job, backup, dan proses terjadwal | Job memanggil sebuah URL setiap kali berhasil. Alert muncul kalau panggilan yang ditunggu tidak datang |
Push monitor sangat berguna untuk job terjadwal yang tidak punya endpoint untuk dicek. Script backup, misalnya, memanggil URL push setelah selesai. Kalau panggilan itu tidak datang sesuai jadwal, Uptime Kuma mengirim alert. Monitor HTTP juga bisa mengecek masa berlaku sertifikat TLS dan memberi peringatan jauh sebelum sertifikatnya habis.
Atur Retry dan Notifikasi Supaya Alert Tetap Dipercaya
Satu kali pengecekan gagal belum tentu berarti layanan down. Gangguan jaringan sesaat bisa membuat satu pengecekan gagal, dan kalau setiap kegagalan langsung mengirim notifikasi, tim akan cepat terbiasa mengabaikannya. Pakai retry supaya Uptime Kuma memastikan kegagalannya berulang dulu sebelum menganggapnya insiden.
- Tentukan interval pengecekan dari seberapa cepat gangguan perlu diketahui. 60 detik adalah titik awal yang wajar. Interval yang lebih pendek biasanya hanya menambah beban tanpa mempercepat penanganan.
- Pakai retry dengan jeda yang lebih singkat, supaya gangguan sungguhan tetap terkonfirmasi dalam satu sampai dua menit, sementara request yang sesekali gagal tidak memicu alert.
- Nyalakan opsi resend supaya insiden yang belum selesai mengirim notifikasi ulang secara berkala. Satu pesan yang terlewat jadi tidak berujung gangguan yang tidak disadari.
- Pasang minimal dua kanal notifikasi untuk monitor yang penting. Integrasi yang rusak atau bot Telegram yang terkena rate limit bisa membuat semua alert hilang tanpa jejak.
- Buat maintenance window sebelum pekerjaan terencana, supaya downtime yang sudah diketahui tidak membangunkan orang dan tidak tercatat sebagai insiden di status page.
- Pisahkan tujuan notifikasi berdasarkan tingkat kepentingan. Kalau semua monitor dikirim ke satu grup yang sama, alert yang butuh tindakan cepat tenggelam di antara pesan informasi.
Pakai Status Page untuk Memberi Kabar ke Pengguna
Uptime Kuma bisa membuat status page yang menampilkan kondisi layanan ke pengguna. Saat ada gangguan, halaman ini mengurangi pertanyaan yang sama berulang kali ke tim support, karena pengguna bisa langsung melihat layanan apa yang terdampak dan sudah sampai mana penanganannya.
Taruh status page di luar infrastruktur yang dilaporkannya. Pakai juga nama layanan yang dimengerti pengguna. "Pembayaran" jauh lebih jelas bagi pelanggan daripada nama internal seperti "api-gateway-02".
Perawatan Uptime Kuma
- Semua konfigurasi dan riwayat tersimpan di satu folder data. Folder ini harus berupa volume persisten dan ikut di-backup. Kalau container dibuat ulang tanpa data itu, semua monitor harus disusun ulang dari nol.
- Taruh antarmukanya di belakang reverse proxy dengan TLS, batasi akses admin, dan aktifkan autentikasi dua faktor. Instance ini menyimpan token notifikasi dan berisi peta seluruh layanan Anda.
- Update secara rutin. Untuk deployment satu container, update-nya sederhana, dan software monitoring yang setahun tidak di-update adalah risiko yang tidak perlu di server yang terbuka ke internet.
- Perhatikan jumlah monitor sekaligus frekuensi pengecekannya. Ratusan monitor dengan interval pendek di instance paling kecil akan membuat pengecekan tertunda, dan hasilnya terlihat seperti alarm palsu.
- Cek daftar monitor setiap tiga bulan. Layanan yang sudah dimatikan tapi monitornya masih ada akan terus memicu alert, sementara layanan yang baru ditambahkan sering belum dipantau sama sekali.
Urutan Penerapan Uptime Kuma
- 1Buat daftar layanan yang berdampak ke pengguna beserta penanggung jawabnya sebelum membuat monitor. Alert yang tidak punya pemilik tidak akan diurus siapa pun.
- 2Pasang instance di luar lingkungan yang dipantau, lengkap dengan penyimpanan persisten, TLS, dan pembatasan akses admin dari hari pertama.
- 3Buat monitor untuk alur yang paling penting bagi pengguna dulu, dengan pengecekan keyword atau JSON untuk layanan yang tidak cukup dicek dari status code.
- 4Tambahkan push monitor untuk backup dan job terjadwal. Backup yang diam-diam gagal biasanya baru ketahuan tepat saat datanya dibutuhkan.
- 5Atur retry, resend, dan minimal dua kanal notifikasi. Lalu tes jalur alert-nya dengan sengaja menggagalkan satu monitor percobaan.
- 6Terbitkan status page dengan nama layanan yang dimengerti pengguna, dan sepakati siapa yang memperbarui informasi insiden saat terjadi gangguan.
Tanda Setup-nya Sudah Benar
- Setiap notifikasi yang masuk punya alasan jelas dan butuh tindakan.
- Instance monitoring tetap hidup walaupun server aplikasi mati.
- Maintenance terencana tidak memicu alert.
- Pengguna mengecek status page lebih dulu sebelum menghubungi support.
- Data uptime bisa dipakai dalam evaluasi layanan karena dikumpulkan dari luar sistem.
Ingat juga batasnya. Uptime Kuma memberi tahu bahwa layanan tidak merespons sesuai pengecekan, tapi tidak menjelaskan penyebabnya. Untuk mencari akar masalah, tim tetap butuh log, metrik server, dan tool seperti Zabbix atau APM.
Poin penting
- Pasang Uptime Kuma di luar infrastruktur yang dipantau. Monitoring yang ikut mati bersama aplikasinya tidak bisa melaporkan apa-apa.
- Pilih jenis monitor sesuai cara layanan bisa gagal. Pengecekan keyword dan JSON menangkap aplikasi yang error tapi tetap mengembalikan status 200.
- Pakai push monitor untuk backup dan job terjadwal, karena di sinilah kegagalan paling sering terjadi tanpa ada yang tahu.
- Atur retry, resend, dan kanal notifikasi cadangan, lalu tes jalur alert-nya dengan sengaja.
