Cara Membuat Halaman Status: Komponen, Insiden dan Cek Uptime

Halaman status memberi tahu pengguna Anda, di satu tempat, apakah layanan Anda berfungsi. Untuk membuatnya, Anda membutuhkan daftar komponen (situs web, API, pembayaran, pengiriman email), status saat ini untuk tiap komponen, insiden dengan pembaruan berstempel waktu, riwayat insiden yang sudah lewat, dan opsional langganan agar orang mendapat kabar saat ada masalah tanpa harus mengecek sendiri. Halamannya sendiri sederhana. Keputusan yang penting adalah di mana halaman itu berjalan: halaman status harus tetap aktif saat aplikasi Anda mati, jadi jangan berbagi hosting, database, atau pipeline deploy dengan hal yang dilaporkannya.

Untuk apa halaman status

Saat ada yang rusak, pengguna ingin tahu tiga hal: apakah cuma saya yang kena, apakah Anda sudah tahu, dan kapan akan diperbaiki. Halaman status menjawab ketiganya tanpa membanjiri tiket dukungan. Halaman ini juga membangun kepercayaan seiring waktu, karena riwayat insiden yang terbuka dengan penjelasan jujur menunjukkan bagaimana Anda menangani masalah.

Ini bukan changelog. Fitur baru masuk ke halaman changelog; gangguan dan pemeliharaan masuk ke sini.

Yang dibutuhkan halaman

Data

Status komponen biasanya berupa daftar tetap yang pendek: Operational, Degraded performance, Partial outage, Major outage, Under maintenance.

Halaman

• Halaman status publik: banner ringkasan (“Semua sistem berfungsi” atau status terburuk saat ini), tiap komponen dengan statusnya, insiden aktif beserta pembaruannya, pemeliharaan yang akan datang, dan strip riwayat 90 hari jika Anda punya data pengecekan.
• Halaman insiden: linimasa lengkap pembaruan untuk satu insiden, dengan URL sendiri agar tim dukungan bisa membagikannya.
• Riwayat: insiden yang sudah lewat, dikelompokkan per bulan.
• Berlangganan: pendaftaran email dengan konfirmasi dan preferensi per komponen.
• Admin: membuat insiden, memposting pembaruan, mengubah status komponen, menjadwalkan pemeliharaan.

Izin

Publik melihat semua yang sudah dipublikasikan. Hanya tim Anda yang bisa memposting. Pisahkan login admin dari sistem login aplikasi utama jika memungkinkan, agar gangguan pada penyedia autentikasi tidak mengunci Anda dari halaman status sendiri.

Keputusan kunci: buat tetap independen

Di sinilah sebagian besar halaman status buatan sendiri gagal. Jika halaman status Anda:

• berjalan di server atau akun hosting yang sama dengan aplikasi,
• membaca dari database yang sama,
• berada di balik pengaturan domain atau CDN yang sama,
• atau di-deploy lewat pipeline yang sama,

maka banyak gangguan juga akan mematikannya, tepat saat orang membutuhkannya. Langkah praktisnya:

• Hosting terpisah. Proyek atau penyedia yang berbeda dari aplikasi utama.
• Subdomain sendiri, misalnya status.contoh.com, diarahkan terpisah di DNS. Lihat cara kerja domain dan DNS.
• Datanya sendiri. Insiden disimpan di penyimpanan halaman status, bukan di database aplikasi.
• Cadangan statis. Sebagian tim membuat halaman publik sebagai statis dan membangunnya ulang setiap ada pembaruan, sehingga hampir tidak ada yang bisa rusak.

Pembaruan manual atau cek otomatis

Manual (mulai dari sini)

Tim Anda memposting insiden dan mengubah status komponen secara manual dari halaman admin. Begitulah banyak halaman status bekerja dalam praktik, karena penilaian manusia (“pembayaran lambat untuk beberapa jenis kartu”) lebih berguna daripada titik merah otomatis.

Untuk mengetahui masalah dengan cepat, gunakan pemantau uptime eksternal yang mengecek aplikasi Anda kira-kira setiap menit dan memberi peringatan lewat email, SMS, atau chat. Banyak layanan pemantauan punya paket gratis.

Otomatis

Otomatisasi berarti ada sesuatu yang secara berkala memeriksa tiap komponen dan memperbarui statusnya. Itu membutuhkan kode yang berjalan terjadwal, dari luar infrastruktur aplikasi utama Anda. Dua pola yang umum:

• Pemantau eksternal memanggil halaman status Anda lewat webhook saat pengecekan gagal atau pulih, dan halaman status memperbarui komponennya.
• Tugas terjadwal di hosting halaman status itu sendiri yang melakukan ping ke tiap komponen dan mencatat hasilnya. Periksa dulu cara hosting Anda menangani tugas terjadwal sebelum mengandalkannya; panduan kami tentang menjalankan background job menjelaskan pilihannya.

Perubahan otomatis bisa naik-turun (up, down, up lagi) pada jaringan yang lambat. Minta dua atau tiga kegagalan berturut-turut sebelum status diubah, dan biarkan manusia mengonfirmasi sebelum gangguan besar diumumkan.

Menulis pembaruan insiden

• Posting lebih awal. “Kami sedang menyelidiki laporan login yang gagal” dalam hitungan menit lebih baik daripada pesan yang sempurna satu jam kemudian.
• Sebutkan apa yang dirasakan pengguna, bukan apa yang rusak secara internal.
• Janjikan waktu pembaruan berikutnya, lalu tepati.
• Tutup dengan ringkasan singkat setelah selesai: apa yang terjadi, berapa lama, dan apa yang akan Anda ubah.

Prompt pertama yang berhasil

Buat halaman status mandiri untuk aplikasi kami Parcelio, di-hosting terpisah di status.parcelio.com. Komponen: Website, Tracking API, Notifications, Payments, masing-masing dengan status Operational, Degraded performance, Partial outage, Major outage, atau Under maintenance. Halaman publik menampilkan banner ringkasan memakai status terburuk saat ini, tiap komponen beserta statusnya, insiden aktif dengan pembaruan berstempel waktu dari yang terbaru, pemeliharaan yang akan datang, dan daftar insiden lampau per bulan. Setiap insiden punya halamannya sendiri. Tambahkan halaman admin yang dilindungi kata sandi untuk membuat insiden (judul, dampak, komponen terdampak), memposting pembaruan (pesan dan status: Investigating, Identified, Monitoring, Resolved), mengubah status komponen, dan menjadwalkan pemeliharaan. Tambahkan endpoint POST /api/check-result yang menerima nama komponen dan up/down dari pemantau eksternal, dilindungi token rahasia, dan hanya menandai komponen sebagai Degraded setelah tiga kali down berturut-turut. Simpan semuanya di database aplikasi ini sendiri. Desain sederhana dan tenang yang memuat cepat di ponsel.

Langkah pembuatan

1. Halaman publik dan admin dengan insiden manual. Ini saja sudah menjadi halaman status yang berfungsi.
2. Hosting terpisah dan arahkan subdomain ke sana.
3. Halaman insiden dan riwayat.
4. Jendela pemeliharaan.
5. Langganan. Pendaftaran email dengan double opt-in dan notifikasi saat ada insiden atau pembaruan baru. Email membutuhkan penyedia; lihat cara mengirim email dari aplikasi Anda.
6. Webhook pemantau jika Anda ingin perubahan status otomatis.
7. Jalankan simulasi. Buat insiden palsu, posting pembaruan, selesaikan, cek emailnya, lalu hapus.

Kesalahan umum

• Meng-hosting-nya bersama aplikasi. Ini kesalahan paling umum dan paling serius.
• Halaman yang selalu menulis “Semua sistem berfungsi”. Jika tidak pernah menampilkan masalah, pengguna berhenti mempercayainya.
• Tidak ada stempel waktu atau zona waktu. Selalu tampilkan waktu beserta zonanya.
• Mengandalkan login aplikasi utama untuk halaman admin.
• Diam di antara pembaruan. “Belum ada perubahan, masih dikerjakan” adalah pembaruan yang sah.
• Status otomatis yang naik-turun. Minta kegagalan berulang sebelum perubahan.

Kapan layanan halaman status siap pakai lebih baik

Layanan halaman status siap pakai dibangun untuk masalah independensi: mereka berjalan di infrastruktur terpisah, menangani notifikasi pelanggan lewat email dan SMS, dan sering kali sudah mencakup pemantauan serta integrasi dengan alat insiden. Jika uptime adalah bagian dari yang dibayar pelanggan, atau Anda punya kewajiban kontrak untuk melaporkan insiden, layanan khusus biasanya sepadan. Banyak yang punya paket gratis atau murah untuk tim kecil, jadi periksa dulu sebelum membangun sendiri.

Bangun sendiri jika Anda ingin kendali penuh atas desain dan kata-katanya, kebutuhan Anda sederhana (beberapa komponen, pembaruan manual), atau halaman status menjadi bagian dari produk yang Anda buat untuk orang lain.

Membangunnya dengan Mythex

Di Mythex, Anda bisa membangun halaman status sebagai proyek tersendiri, terpisah dari aplikasi utama, sehingga punya hosting dan database sendiri. Jelaskan di chat, periksa di pratinjau langsung, lalu publikasikan dan hubungkan subdomain seperti status.domainanda.com (domain kustom tersedia di Pro). Perlu diingat bahwa aplikasi Mythex yang sudah dipublikasikan beserta database-nya tidur saat tidak dipakai dan bangun saat ada kunjungan berikutnya, jadi pemuatan pertama setelah lama tidak dibuka bisa lebih lambat; halaman yang sederhana dan ringan membantu.

Mythex belum mendokumentasikan tugas terjadwal, jadi untuk pengecekan otomatis gunakan pemantau uptime eksternal yang memanggil endpoint webhook di halaman status Anda (lihat resep webhook). Email pemberitahuan ke pelanggan lewat penyedia Anda sendiri, dengan kuncinya disimpan sebagai secret proyek (resep kirim email).

Pertanyaan