Log & Status

Memeriksa apakah deploy berhasil, memahami kondisi aplikasi saat ini, dan membaca log-nya.

Status aplikasi

Halaman Status App adalah satu-satunya tempat yang menampilkan seluruh kondisi aplikasi saat ini dalam sekali lihat: release aktif, build di baliknya, replica yang berjalan, dan domain-domainnya.

Deploy bersifat asinkron, jadi halaman ini adalah tempat Anda memantau prosesnya — halaman diperbarui seiring deploy bergerak melalui status-statusnya:

  • pending — deploy sudah diterima dan akan segera dimulai.
  • building — kode sumber Anda sedang di-build menjadi container image.
  • waiting_for_server — build sudah selesai (atau masih berjalan), dan Raklane sedang menyalakan server yang punya ruang untuk aplikasi Anda. Biasanya beberapa menit; prosesnya berlanjut sendiri.
  • rolling_out — replica baru sedang menyala dan diperiksa kesehatannya di samping yang lama.
  • active — release sudah live dan melayani trafik.
  • baking — trafik sudah dipindahkan, tetapi Raklane masih menyalakan release sebelumnya sebagai jaring pengaman selama rentang waktu singkat (lihat Men-deploy Aplikasi).
  • failed — build atau health check replica baru gagal; apa pun yang berjalan sebelumnya tetap utuh dan masih melayani trafik.
  • canceled — Anda membatalkan deploy sebelum selesai.
  • rolled_back — masalah terdeteksi selama bake window dan Raklane otomatis kembali ke release sebelumnya.
  • unreachable — Raklane saat ini tidak bisa memastikan kondisi release, biasanya karena server BYOC tempatnya berjalan sedang offline. Aplikasi sering kali tetap berjalan dan melayani. Status kembali ke active dengan sendirinya setelah server terhubung lagi.

Jika sebuah App belum pernah di-deploy, halaman status hanya menunjukkan hal itu — bukan error, tidak ada yang rusak, hanya belum ada yang berjalan.

Membaca log

Raklane menyimpan dua jenis log yang terpisah:

  • Build log — output dari proses mengubah kode sumber menjadi container image (instalasi dependensi, deteksi buildpack, langkah kompilasi). Log ini dikelompokkan per tahap, sehingga Anda bisa langsung melompat ke, misalnya, tahap instalasi dependensi tanpa menggulir seluruh build. Di sinilah tempat mencari tahu saat deploy gagal sebelum container sempat menyala.
  • Runtime log — gabungan stdout/stderr container yang berjalan, persis seperti yang dicetak aplikasi Anda. Di sinilah tempat mencari stack trace, error saat startup, atau apa pun yang dicatat aplikasi saat sudah berjalan.

Halaman Status memberi tahu bahwa ada yang gagal dan sering kali alasan strukturalnya (misalnya health check timeout atau gagal menarik image), tetapi bukan output aslinya — pesan error yang sebenarnya ada di Logs.

Log mengikuti deploy terbaru App, berhasil atau tidak — jadi jika deploy gagal, log-nya adalah tempat yang tepat untuk mencari tahu penyebabnya.

Urutan pemecahan masalah yang umum

  1. Periksa halaman Status — apakah release failed, atau masih berjalan (building, waiting_for_server, rolling_out)?
  2. Jika failed, periksa alasan kegagalan yang ditampilkan — biasanya menunjukkan apakah masalahnya ada di build atau di container yang gagal health check.
  3. Periksa Logs untuk output aplikasi di sekitar waktu kegagalan — hampir selalu di sinilah pesan error yang sebenarnya.

Jika aplikasi berjalan tetapi lambat, crash saat beban tinggi, atau dihentikan paksa, periksa Metrik & Proses — kejadian out-of-memory dan CPU throttling muncul di sana, beserta saran apa yang perlu diubah.

Lihat Pemecahan Masalah untuk solusi masalah spesifik yang paling mungkin Anda temui.