Status Page Publik yang Iseng Kupasang, Ternyata Jadi Alasan Klien Pertama Mau Bayar Tahunan

Selasa siang, seseorang dari tim ops sebuah startup logistik kecil japri lewat form kontak: "Sebelum kami upgrade ke paket tahunan, boleh lihat riwayat downtime-nya nggak?" Pertanyaan itu bikin aku diam beberapa detik di depan laptop. Tracker langganan yang kubangun sendiri ini punya riwayat yang, jujur saja, tidak bersih-bersih amat—ada bulan waktu backup-nya diam-diam kosong sebelas minggu, ada malam webhook payment nge-charge dobel karena aku salah asumsi soal retry. Insting pertamaku adalah menjawab seadanya dan berharap dia tidak menggali lebih dalam. Tapi aku sudah lama menyimpan draft status page publik yang belum pernah kupublikasikan karena takut malah menunjukkan borok sendiri. Sore itu aku putuskan: publikasikan saja, apa adanya.

Kenapa Aku Nyaris Tidak Jadi Pasang Ini

Alasan aku menunda status page selama berbulan-bulan sebenarnya sederhana: rasanya seperti sengaja memasang papan pengumuman berisi daftar kesalahanku sendiri. Proyek ini kupegang sendirian, dari kode sampai balas email support, dan setiap insiden yang tercatat rasanya personal. Tapi setelah insiden backup kosong itu aku mulai menulis catatan pasca-insiden untuk diriku sendiri—apa yang rusak, kenapa rusak, apa yang kuubah supaya tidak terulang. Catatan itu makin lama makin rapi, dan pada satu titik aku sadar: ini sebenarnya sudah separuh jadi konten yang orang lain justru ingin baca, bukan yang perlu disembunyikan.

Bedanya dengan status page kebanyakan SaaS besar yang cuma menampilkan lingkaran hijau "All Systems Operational", punyaku dari awal kurancang untuk menyertakan tautan ke catatan pasca-insiden di setiap downtime yang tercatat. Bukan cuma "downtime 47 menit", tapi juga apa akar masalahnya dan langkah konkret yang sudah kuambil. Rasanya berlawanan dengan insting, tapi aku menduga—dan ternyata benar—bahwa orang yang serius mengevaluasi sebuah tool kecil justru lebih curiga kalau riwayatnya terlalu bersih daripada kalau ada catatan jujur tentang apa yang pernah salah.

Bagian Teknis: Bukan Tool Mahal, Cuma Cron dan Satu Tabel

Aku tidak berlangganan layanan status page pihak ketiga—anggaran proyek sampingan ini masih terlalu tipis untuk itu. Yang kubangun cuma satu tabel incidents di database yang sama, satu cron job kecil tiap lima menit yang melakukan health check ke endpoint utama dan worker webhook, dan satu halaman statis yang di-generate ulang setiap kali ada perubahan status. Kalau health check gagal dua kali berturut-turut, sistem otomatis membuka entri insiden baru berstatus "investigating"; aku yang menutupnya manual dengan ringkasan singkat begitu masalah selesai dan akar penyebabnya jelas.

Bagian yang paling kuhargai justru bukan otomatisasinya, tapi disiplin menulis ringkasan pasca-insiden dalam bahasa yang bisa dipahami orang non-teknis—bukan "race condition di queue worker", tapi "dua proses memproses transaksi yang sama secara bersamaan, sekarang dicegah dengan penguncian per-transaksi". Menulis ulang insiden lama seperti itu ternyata juga memaksa aku memeriksa ulang apakah perbaikannya benar-benar tuntas, bukan cuma tambal yang kelihatan beres di permukaan.

Momen Waktu Itu Berbalik Jadi Kepercayaan

Balik ke telepon Selasa siang itu. Aku kirim tautan status page-nya langsung, tanpa embel-embel penjelasan defensif. Orang di seberang sempat diam sebentar juga—lalu justru bertanya lebih detail soal insiden backup kosong itu: apa yang berubah setelahnya. Aku jelaskan bahwa sekarang ada verifikasi otomatis mingguan yang benar-benar mencoba memulihkan backup ke database sementara, bukan cuma mengecek ukuran file dump. Dia bilang itu justru lebih meyakinkan dibanding vendor lama mereka yang status page-nya selalu hijau sempurna tapi tetap saja pernah down tanpa penjelasan apa pun ke pelanggan.

Minggu berikutnya mereka upgrade ke paket tahunan—klien berbayar tahunan pertamaku sejak proyek ini jalan, di tengah pelanggan-pelanggan lain yang selama ini semuanya bulanan. Bukan karena fiturnya bertambah atau harganya turun. Satu-satunya yang berubah minggu itu adalah mereka bisa melihat, hitam di atas putih, bahwa setiap kali sesuatu rusak, ada orang di baliknya yang benar-benar mengerti kenapa dan sudah membenahi akar masalahnya—bukan sekadar restart layanan dan berharap tidak terulang.

Yang Kuubah dalam Cara Aku Kerja Sejak Itu

Sejak itu aku mengubah kebiasaan kecil: setiap kali ada insiden, sebelum menutup tiket internal, aku paksa diriku menulis ringkasan pasca-insiden dalam sepuluh menit selagi detailnya masih segar—bukan menundanya sampai "nanti kalau sempat", yang biasanya berarti tidak pernah. Aku juga berhenti menganggap status page sebagai formalitas yang cuma dilihat pas ada gangguan; sekarang ada dua-tiga calon pelanggan tiap bulan yang membukanya duluan sebelum bertanya apa pun ke aku, dan itu justru mempercepat obrolan penjualan karena pertanyaan dasar soal keandalan sudah terjawab sebelum kami mulai bicara.

Takeaway

Transparansi soal insiden lama terasa seperti risiko sebelum dicoba, tapi untuk proyek kecil yang dijalankan satu orang, itu sering jadi satu-satunya bukti kredibilitas yang bisa ditunjukkan tanpa nama besar atau tim support 24 jam. Kalau ada bug atau downtime yang sudah kamu perbaiki dengan benar, catatan jujur tentangnya bukan aib yang perlu disembunyikan—itu aset yang bisa jadi pembeda saat calon klien membandingkan kamu dengan vendor besar yang riwayatnya tampak sempurna tapi tidak pernah benar-benar transparan.

---

Sumber gambar: Chris Ried di Unsplash Sumber gambar: Glenn Carstens-Peters di Unsplash Sumber gambar: Domaintechnik di Unsplash