Instalasi n8n Saya Rusak Dua Belas Hari, dan Tidak Ada yang Bunyi

Instalasi n8n di VPS kantor saya rusak di tengah proses install, dan selama dua belas hari tidak ada yang tahu. Lead dari website tetap sampai ke sales seperti biasa. Yang akhirnya sadar saya sendiri, saat n8n mulai membalas 503 ke setiap request.

Penyebabnya install yang terpotong di tengah jalan. Install itu terlihat menggantung, lalu saya hentikan, padahal waktu itu install n8n di server tersebut memang makan sekitar 22 menit dan lama tidak mengeluarkan output. Perbaikannya install ulang bersih.

Tagihan VPS n8n Edavos tujuh bulan terakhir ada di antara Rp 86,196 dan Rp 89,176 per bulan (perbandingannya dengan Apps Script di sini). Tagihan itu tidak memuat satu pun dari lima lapisan di bawah. Empat di antaranya saya pasang sesudah kegagalan yang tidak memicu alarm apa pun, dan yang kelima karena perbaikan untuk salah satunya mematikan alarm yang sudah ada.

Apa yang perlu dipantau di n8n self-hosted?

Ada lima hal yang perlu dipantau: apakah database bisa dipulihkan, apakah n8n sehat dan bukan cuma hidup, apakah server bisa dijangkau dari luar, apakah ada workflow yang gagal, dan apakah kegagalan yang sudah ditangkap jalur error tetap dilaporkan. Di n8n self-hosted Edavos, kelimanya saya pasang sendiri, dan Error Trigger bawaan n8n baru menutup yang keempat setelah dipasang sebagai error workflow di tiap workflow.

Proses yang hidup belum tentu sehat

Saat n8n membalas 503 ke setiap request, prosesnya tidak mati. systemd sudah disetel Restart=on-failure, tapi pengaturan itu cuma bereaksi kalau prosesnya keluar. Proses n8n tetap berjalan di atas instalasi yang rusak, jadi systemd melihatnya sehat.

n8n punya dua endpoint kesehatan, dan bedanya menentukan. Menurut dokumentasi monitoring n8n, /healthz membalas 200 selama instance bisa dijangkau tanpa melihat database, sedangkan /healthz/readiness baru membalas 200 kalau database tersambung dan sudah dimigrasi.

Karena itu semua monitor n8n di Edavos memakai readiness. Di kasus awal artikel ini, prosesnya hidup sementara readiness membalas 503.

Watchdog di dalam VPS mengecek readiness tiap 5 menit lewat cron. Ini bagian skripnya yang memutuskan restart atau tidak:

FAIL_THRESHOLD=2          # 2x gagal berturut (=10 menit) baru restart

FAILS=$((PREV_FAILS + 1))
log "GAGAL ke-$FAILS: readiness HTTP $CODE"

if [ "$FAILS" -lt "$FAIL_THRESHOLD" ]; then
  # Sekali gagal bisa cuma glitch/restart wajar. Tunggu siklus berikutnya.
  printf "%s\n%s\n" "$FAILS" "$PREV_STATE" > "$STATE"
  exit 0
fi

BIN_OK=$( [ -L /usr/bin/n8n ] && echo ya || echo TIDAK )
PKG_OK=$( [ -f /usr/lib/node_modules/n8n/package.json ] && echo ya || echo TIDAK )

if [ "$BIN_OK" = "TIDAK" ] || [ "$PKG_OK" = "TIDAK" ]; then
  # (notifikasi RUSAK ke Telegram, dipotong)
  log "RUSAK: instalasi tidak utuh, restart dilewati"
  printf "%s\ndown\n" "$FAILS" > "$STATE"
  exit 1
fi

log "RESTART: mencoba systemctl restart n8n"
sudo -n systemctl restart n8n 2>>"$LOG"
sleep 90

Dua keputusan di skrip itu menahan watchdog dari bertindak berlebihan. Gagal sekali tidak memicu apa pun, karena restart wajar dan glitch singkat juga membalas selain 200. Kalau symlink /usr/bin/n8n atau package.json hilang, watchdog tidak me-restart, karena restart tidak menyembuhkan instalasi yang rusak, dan langsung meminta install ulang.

Notifikasi hanya dikirim saat status berganti, dari sehat ke bermasalah atau sebaliknya. Tanpa aturan itu, n8n yang down mengirim pesan yang sama tiap 5 menit.

Dua monitor yang sengaja tidak bunyi bersamaan

Watchdog jalan di dalam VPS, jadi kalau VPS-nya mati atau jaringannya putus, watchdog ikut buta. Celah itu ditutup Better Stack, yang mengecek readiness dari luar tiap 3 menit lewat domain publik. Dua monitor yang memantau hal yang sama akan bunyi bersamaan untuk satu masalah, kecuali urutannya diatur.

Urutannya ditentukan masa konfirmasi Better Stack, yang saya pasang 15 menit. Di menit 10 watchdog sudah melihat dua kali gagal dan me-restart n8n, dan n8n siap lagi sekitar dua setengah menit kemudian. Di menit 15 masa konfirmasi habis, readiness sudah 200, dan Better Stack tidak membuka incident.

Hasilnya Better Stack hanya bunyi kalau watchdog gagal memperbaiki. Kalau masa konfirmasi diturunkan, alarm bunyi persis saat watchdog sedang bekerja.

Response time sengaja tidak dipantau. Respons n8n melambat saat backup jam 02:00 atau saat workflow berat jalan, dan alarm dari situ palsu.

Server sehat, workflow gagal

Watchdog dan Better Stack sama-sama hijau saat sebuah workflow gagal di tengah jalan. Kasusnya pernah terjadi di alur lead Edavos: satu kolom dihapus dari sheet pencatat, node pencatat menolak append, dan 7 lead tidak sampai ke sales sampai tim menemukannya sendiri.

Lapisan keempat adalah satu workflow Error Alert. Error Trigger menerima kegagalan dan meneruskannya ke Code node yang memformat dan menyaring, lalu hasilnya dikirim lewat HTTP POST ke webhook space Google Chat khusus error n8n. Space itu sengaja dipisah dari alarm infrastruktur lain, karena orang yang menanggapinya berbeda dan alarm n8n yang jarang tidak boleh tenggelam.

Error Alert dipasang sebagai error workflow di ketiga workflow aktif. Error Alert sendiri harus berstatus published, karena n8n 2.x menolak error workflow yang belum published.

Filter yang menentukan alarm dibaca atau diabaikan

Di hari normal, dua workflow file organizer menghasilkan sekitar 2 error timeout per hari di trigger polling Google Drive. Semuanya pulih sendiri, karena kursor trigger tidak maju saat gagal dan file yang sama terambil di siklus berikutnya. Code node di Error Alert membuang timeout dan koneksi putus dari trigger itu, sedangkan error lain dari node yang sama, misalnya auth, tetap diteruskan.

Jalan pintasnya menyalakan Retry on Fail di trigger itu, dan itu tidak menolong. Di source n8n versi yang saya pakai, pengaturan itu tidak dibaca untuk trigger polling.

Untuk node biasa pengaturannya bekerja, jadi node Download File di workflow yang sama diberi 3 percobaan berjeda 5 detik. Di node ini kegagalan lebih mahal. Trigger sudah menganggap file-nya terambil, jadi file yang gagal diunduh tidak akan diambil lagi.

Jalur error yang menelan alarm

Lapisan kelima lahir dari perbaikan alur lead. Node pencatat lead diberi jalur error supaya lead tetap terkirim ke sales walau pencatatan gagal. Sejak itu, di instance saya Error Alert tidak terpicu untuk kegagalan pencatatan, karena kegagalannya sudah ditangkap jalur error.

Jadi jalur error itu mengirim alert sendiri ke space yang sama, dengan 3 percobaan kalau pengirimannya gagal.

Kenapa error n8n tidak saya kirim ke AI untuk diperbaiki otomatis

Error n8n di Edavos tidak saya serahkan ke agent AI karena hampir semuanya tidak butuh perbaikan. Dari 70 eksekusi gagal dalam 7 hari, batas retensi log eksekusi n8n Edavos, 65 adalah gangguan jaringan sesaat dan 5 berasal dari satu insiden yang butuh keputusan manusia.

Dari 65 gangguan jaringan itu, hanya 2 yang meninggalkan pekerjaan, dan pekerjaannya mengambil ulang file. Angka 62 di baris pertama juga lebih besar dari hitungan hari normal karena jendela 7 hari itu memuat satu gangguan jaringan VPS yang menggagalkan sekitar 25 eksekusi dalam kurang dari setengah jam.

Agent yang memperbaiki error otomatis akan menghabiskan hampir seluruh kerjanya di kasus yang tidak perlu disentuh. Di 5 kasus sisanya, dia harus memutuskan sesuatu yang seharusnya diputuskan pemilik datanya.

Hitungan ini berubah kalau log Anda didominasi error logika yang berulang dengan perbaikan sempit, misalnya node yang gagal di field yang sama berkali-kali. Tarik eksekusi gagal 7 hari terakhir dan kelompokkan per jenis sebelum membangun apa pun.

Backup yang tidak pernah mendarat

Backup harian ditulis cron di VPS jam 02:00 WIB, berupa dump PostgreSQL terkompresi sekitar 6.8 MB yang disimpan 7 hari. Skripnya batal kalau sisa disk di bawah 1 GB. File ditulis ke .tmp dulu lalu di-rename, jadi tidak pernah ada file backup separuh jadi.

Retensi 7 hari berarti kerusakan yang baru ketahuan setelah seminggu tidak bisa dipulihkan dari VPS. Celah itu ditutup salinan bulanan ke iCloud di Mac saya. Folder salinan itu ternyata tidak menerima satu file pun selama sekitar enam minggu sejak dibuat, dan itu baru ketahuan saat routine bulanan membukanya.

Sekarang langkah pertama tiap routine bulanan adalah melihat file terbaru di folder iCloud itu. Kalau file bulan lalu tidak ada, routine tahu salinannya gagal sebelum mengerjakan hal lain.

Apa yang dicek di perawatan bulanan n8n?

Ada enam langkah tiap tanggal 4: cek kesehatan n8n dan disk, update OS, update n8n untuk versi minor dan patch, reboot kalau OS memintanya, menyalin backup terbaru ke luar server, dan memeriksa log watchdog. Routine-nya jalan di Mac saya karena butuh kunci SSH dan folder backup yang cuma ada di sana, dan apa pun yang butuh keputusan dilaporkan, tidak dieksekusi.

Langkah paling berisiko adalah update n8n, dan aturannya ditulis dari satu update minor yang gagal. n8n terinstal sukses, lalu menolak start karena versi barunya butuh Node.js mayor yang lebih baru dari yang terpasang, dan layanan down sekitar 50 menit. Folder staging sisa npm install --dry-run juga membuat install berikutnya gagal, termasuk install untuk rollback.

Tiga aturan update yang sekarang wajib:

Satu uji sebelum menambah workflow berikutnya

Hentikan service n8n Anda selama 15 menit, lalu catat apakah ada notifikasi yang masuk dan dari lapisan mana. Kalau tidak ada yang masuk, pasang watchdog readiness dan monitor dari luar lebih dulu, karena dua lapisan itu yang menangkap kegagalan seperti di awal artikel ini.