Setelah Uptime Kuma Terpasang: Menyusun Monitoring yang Benar-Benar Bekerja

title: “Setelah Uptime Kuma Terpasang: Menyusun Monitoring yang Benar-Benar Bekerja”

slug: monitoring-uptime-kuma-yang-benar-benar-bekerja

category: info-menarik

tags: AI-Generated, Manajemen VPS, Open-source, Admin Server

keywords: monitoring uptime kuma, jenis monitor uptime kuma, notifikasi uptime kuma, status page

focus_keyword: monitoring Uptime Kuma

meta_description: “Setelah terpasang, lalu apa? Panduan menyusun monitoring Uptime Kuma: jenis monitor yang tepat, retry, notifikasi, sertifikat SSL, dan status page yang jujur.”

sources: https://github.com/louislam/uptime-kuma, https://github.com/louislam/uptime-kuma/releases, https://github.com/louislam/uptime-kuma/wiki

Kalau salah satu layanan di VPS kita tumbang malam ini — Nginx mati, database kehabisan koneksi, atau container Docker diam-diam restart loop — kapan kita akan sadar? Kalau jawabannya “pas ada pengunjung yang komplain”, berarti kita sedang mengandalkan keberuntungan sebagai strategi. Pertanyaan inilah yang semestinya dijawab oleh setup monitoring Uptime Kuma kita.

Kabar baiknya, cara memasang Uptime Kuma di VPS sudah pernah kita bahas tuntas — dari Docker Compose, akun admin, sampai status page publik. Yang hampir tidak pernah dibahas siapa pun adalah bagian sesudahnya: menambahkan dua puluh monitor dalam sepuluh menit itu mudah, tetapi menyusun monitoring yang benar-benar menangkap insiden — tanpa membanjiri ponsel kita dengan alarm palsu — itu bagian yang butuh dipikirkan. Oke, lanjuutt.. Artikel ini fokus ke sana.

Tiga Lapis Monitoring, Bukan Satu Alat

Sebelum bicara pengaturan, luruskan dulu peta besarnya. Ada tiga pertanyaan berbeda, dan tiap pertanyaan butuh alat berbeda:

“Sehat dari dalam?” — dijawab Netdata atau Grafana + Prometheus yang memantau CPU, RAM, disk, dan proses langsung dari dalam server.
“Masih hidup dilihat dari luar?” — dijawab Uptime Kuma, yang me-request URL dan mengecek port persis seperti pengunjung melihatnya.
“Tugas terjadwal benar-benar jalan?” — dijawab Healthchecks yang tahu kalau cron job gagal atau justru tidak pernah dipanggil.

Analoginya: monitoring metrik itu stetoskop yang ditempel ke dada pasien; Uptime Kuma satpam yang memanggil tiap ruangan dan mencatat mana yang tidak menjawab; Healthchecks absensi yang mencatat siapa yang bolos. Keduanya, ketiganya, saling melengkapi — bukan saling menggantikan. Memasang Uptime Kuma lalu melepas Grafana itu seperti memecat dokter begitu satpam datang.

Dan sebelum lanjut: pastikan versi yang kita pakai masih dalam jalur perawatan. Seri aktif per akhir 2026 adalah 2.x — perilis terakhir 2.5.9 pada 31 Oktober 2026 — dengan tag Docker louislam/uptime-kuma:2. Tag :1 sudah legacy, format datanya berbeda, dan migrasinya tidak semudah menarik image baru.

Peta Monitoring Uptime Kuma: Satu Layanan, Satu Cara

Uptime Kuma menyediakan banyak jenis monitor — HTTP(S), HTTP(S) Keyword, TCP port, ping, DNS record, Docker container, sampai Push. Kesalahan paling umum bukan kekurangan jenis, tapi memakai jenis yang salah untuk pekerjaan yang salah:

Frontend (Nginx, halaman landing): cukup monitor HTTP(S) biasa ke URL utama. Kalau balasan 2xx, dia hidup.
Aplikasi yang “hidup tapi rusak”: inilah tempat HTTP(S) Keyword bersinar. Halaman error framework sering tetap membalas status 200. Sisipkan kata yang hanya muncul saat aplikasi sehat — misalnya judul dashboard atau teks tombol login — dan monitor akan gagal kalau kata itu hilang, meski statusnya 200.
Database dan service internal: TCP Port ke 5432 (PostgreSQL), 6379 (Redis), atau port SSH. Tanpa perlu login, cukup tahu pintunya masih dijawab.
Container yang restart loop: monitor Docker Container menandai status container itu sendiri — restart ke-17 dalam sejam tidak akan lolos sebagai “200 OK” hanya karena proxy masih menyembunyikannya.
Skrip dan job eksternal: monitor Push tidak mengecek apa pun; dia menunggu di-ping oleh job kita. Tidak di-ping tepat waktu = alarm.

Pola yang saya pakai di VPS produksi: tiap layanan punya dua monitor — satu keyword dari sisi pengunjung, satu TCP/port dari sisi mesin. Kalau hanya satu yang merah, kita langsung tahu lapisan mana yang bermasalah. Dua-duanya merah, kita tahu servernya (atau jaringannya) yang tumbang.

Interval, Retry, dan Kebisingan Notifikasi

Dua pengaturan kecil ini yang menentukan apakah notifikasi kita bisa dipercaya:

Heartbeat Interval — seberapa sering dicek. Uptime Kuma sanggup turun sampai interval 20 detik, tapi untuk stack VPS normal, 60 detik lebih dari cukup. Interval 20 detik untuk puluhan monitor artinya VPS monitoring sibuk me-request terus dan data heartbeat-nya gemuk tanpa nilai tambah.
Retries — berapa kali gagal berurutan sebelum dianggap benar-benar down. Jangan set 1. Satu timeout 30 detik bisa karena gangguan jaringan sesaat, dan kita tidak ingin dibangunkan jam 3 pagi untuk itu. Dua sampai tiga retry adalah titik manis: alarm tetap datang dalam menit pertama insiden nyata, tapi fluktuasi sekecil apa pun tidak jadi alarm.

Ada juga mode Upside Down — dibalik, “berhasil” dianggap gagal — berguna untuk memantau hal yang justru seharusnya tidak merespons, misalnya port yang semestinya tertutup rapat. Dan untuk target dengan sertifikat self-signed atau yang tengah migrasi, opsi Ignore TLS Error ada, tapi perlakukan dia sebagai pinjaman sementara, bukan pengaturan permanen.

Aturan praktisnya satu: notifikasi yang sering salah adalah notifikasi yang akan di-mute. Begitu refleks kita jadi “ah, alarm palsu lagi”, monitoring sudah kalah — diam-diam, tanpa kita sadari.

Pantau Sertifikat SSL Sebelum Kedaluwarsa

Insiden paling memalukan di dunia monitoring bukan server down, tapi sertifikat kedaluwarsa di halaman status — halaman yang seharusnya jadi bukti kesehatan situs justru memasang peringatan merah di browser pengunjung. Uptime Kuma melihat informasi sertifikat tiap domain yang dia pantau dan punya pengaturan Certificate Expiry untuk memperingatkan kita beberapa hari sebelum masa berlakunya habis.

Dua langkah kecil supaya lapisan ini rapat:

Tambahkan domain status page itu sendiri sebagai monitor — pagari pekerjaan penjaga dengan menjaga penjaganya.
Kalau pakai Let’s Encrypt dengan certbot otomatis, tetap pantau. Renewal otomatis gagal lebih sering daripada yang kita pikir — akun staging yang nyangkut, perubahan plugin DNS, atau rate limit di momen terburuk.

Status Page yang Jujur

Uptime Kuma mendukung banyak status page sekaligus dan bisa memetakan tiap status page ke domain spesifik. Manfaatkan itu untuk memisahkan dua kebutuhan:

Status page publik — untuk pengunjung dan klien: sederhana, hanya layanan yang mereka sentuh, bahasa manusia (“Aplikasi”, bukan “worker-3 di queue redis”).
Status page internal — untuk kita sendiri: lengkap dengan port, container, dan job cron.

Hati-hati satu hal: jangan tampilkan nama host internal, port, atau nama container di status publik. Status page yang terindeks mesin pencari adalah peta gratis untuk siapa pun yang sedang melakukan rekon sebelum menyerang. Jujur itu berarti transparan soal status, bukan borong soal detail.

Jebakan yang Sering Menipu

Bagian ini yang jarang dibahas tutorial lain, padahal di sinilah setup monitoring biasanya gagal diam-diam:

Monitoring mati bersama server yang diawasi. Kalau Uptime Kuma berjalan di VPS yang sama dengan semua layanan yang dia pantau, saat VPS itu sendiri down, sentinel kita ikut tewas — tidak ada siapa-siapa yang mengirim notifikasi. Solusinya: taruh Uptime Kuma di VPS (atau mesin rumah) yang berbeda dari target utamanya. Satu VPS murah memantau VPS produksi, kebalikannya juga.
Sertifikat subdomain status kelupaan. Tambahkan domain status itu sendiri sebagai monitor, dan biarkan pengawas sertifikat yang memperingatkan.
Interval terlalu rapat. Puluhan monitor tiap 20 detik hanya membebani VPS monitoring dan menggembungkan data. 60 detik cukup untuk kebutuhan normal.
Data lama hilang saat pindah server. Semuanya ada di volume /app/data. Cadangkan folder itu secara rutin — docker run --rm -v uptime-kuma:/data -v $PWD:/backup alpine tar czf /backup/uptime-kuma.tgz -C /data . satu baris itu sudah menyelamatkan seluruh konfigurasi kita.
Upgrade sembarangan. Pindah antar major version (1.x ke 2.x) punya prosedur backup dan migrasi sendiri di wiki resminya — baca dulu, baru docker compose pull dan up -d untuk update dalam jalur 2.x.

Kesimpulan

Alat monitoring yang bagus bukan yang punya fitur terbanyak, tapi yang notifikasinya kita percaya. Tiga lapis (metrik internal, uptime eksternal, heartbeat cron), jenis monitor yang tepat per layanan, retry yang tidak gampang panic, sertifikat yang dijaga sebelum kedaluwarsa, dan status page yang jujur tanpa membocorkan detail — itu resep sederhana yang membuat “kalau layanan down malam ini, kapan kita sadar?” punya jawaban: dalam satu menit, di ponsel kita.

Mulailah dari satu layanan paling kritis malam ini, tambahkan dua monitor — keyword dan port — atur retry, dan biarkan semalam membuktikan alarmnya bisa tidur tenang. Kalau besok pagi tidak ada notifikasi palsu, kita sudah lebih baik dari separuh internet.