Error Handling dan Retry di n8n agar Workflow Tidak Putus

Workflow n8n yang mengirim notifikasi pesanan sudah berjalan mulus berminggu-minggu. Lalu suatu malam API pengiriman pesan sempat lambat beberapa detik, satu node gagal, dan eksekusi berhenti di tengah. Pagi harinya tidak ada yang tahu bahwa beberapa pesanan tidak pernah diteruskan ke tim gudang. Kejadian seperti ini bukan soal n8n yang rapuh, melainkan workflow yang belum disiapkan untuk gagal.

n8n menyediakan beberapa alat untuk itu: Retry On Fail untuk mencoba ulang node yang gagal, opsi On Error untuk menentukan apa yang terjadi setelah node gagal, error workflow dengan node Error Trigger untuk melapor, dan node Stop And Error untuk menggagalkan eksekusi dengan sengaja. Dipakai bersama, keempatnya membuat workflow tidak putus diam-diam.

Kenapa jenis kegagalan perlu dibedakan dulu?

Tidak semua error perlu ditangani dengan cara yang sama. Gangguan sementara, seperti timeout, koneksi terputus, atau layanan yang sedang sibuk, biasanya hilang sendiri bila dicoba lagi beberapa detik kemudian. Error permanen, seperti kredensial salah, data tidak valid, atau endpoint yang sudah tidak ada, tidak akan sembuh berapa kali pun dicoba ulang.

Untuk gangguan sementara, jawabannya retry. Untuk error permanen, jawabannya melapor ke manusia dan, bila perlu, menyimpan data yang gagal agar bisa diproses ulang. Mencoba ulang error permanen hanya membuang waktu dan, pada API berbayar, bisa membuang biaya.

Retry On Fail untuk gangguan sementara

Setiap node di n8n punya tab Settings. Di sana ada Retry On Fail, yang menurut dokumentasi membuat node dijalankan ulang ketika eksekusinya gagal. Saat diaktifkan, kamu bisa mengatur jumlah percobaan maksimum (Max Tries) dan jeda antar percobaan (Wait Between Tries).

Aktifkan retry pada node yang berbicara dengan layanan luar: HTTP Request ke API pihak ketiga, node model AI, node pengirim email atau pesan, dan node database yang tersambung lewat jaringan. Beri jeda yang wajar, beberapa detik, karena mencoba ulang terlalu cepat sering mengenai gangguan yang sama.

Hati-hati dengan node yang tidak aman diulang. Node yang membuat pesanan, menagih pembayaran, atau mengirim pesan ke pelanggan bisa menghasilkan duplikat bila percobaan pertama sebenarnya berhasil di sisi server tetapi responsnya tidak sampai. Untuk node seperti ini, pastikan API tujuan mendukung kunci idempotensi atau periksa dulu apakah data sudah ada sebelum mengulang.

Opsi On Error, kegagalan menjadi cabang

Di tab Settings yang sama ada opsi On Error dengan tiga pilihan:

• Stop Workflow: menghentikan seluruh workflow ketika node gagal. Ini perilaku yang aman untuk langkah penting.
• Continue: lanjut ke node berikutnya memakai data valid terakhir. Praktis, tetapi bisa menyembunyikan masalah bila tidak diperiksa.
• Continue (using error output): node mendapat keluaran tambahan khusus error, sehingga kegagalan bisa dialirkan ke cabang sendiri.

Pilihan ketiga paling berguna untuk workflow yang memproses banyak item. Misalnya workflow mengirim 50 email. Bila satu alamat ditolak, kamu tidak ingin 49 email lainnya ikut batal. Dengan error output, item yang gagal dialirkan ke cabang yang mencatatnya ke spreadsheet atau database, sementara item lain tetap jalan.

Pilihan Continue biasa sebaiknya dipakai hanya bila kamu benar-benar tidak peduli pada hasil node itu, misalnya mencatat log tambahan yang tidak kritis.

Error workflow, supaya kegagalan tidak senyap

Retry dan cabang error menangani masalah di dalam workflow. Error workflow memastikan kamu tahu ketika semua itu tetap gagal. Caranya:

Buat workflow baru dengan node Error Trigger sebagai node pertama, misalnya diberi nama "Error Handler". Di workflow yang ingin dipantau, buka pengaturan workflow, pilih "Error Handler" di bagian Error workflow, lalu simpan. Satu error workflow bisa dipakai oleh banyak workflow sekaligus.

Error Trigger menerima data tentang eksekusi yang gagal, antara lain nama dan ID workflow, pesan error, node terakhir yang dijalankan, dan tautan ke eksekusinya. Dokumentasi n8n mencatat bahwa ID dan tautan eksekusi hanya tersedia bila eksekusi disimpan di database. Dari data ini, kirim notifikasi ke Telegram, Slack, atau email tim berisi nama workflow, pesan error, dan tautan eksekusi, sehingga siapa pun yang menerima bisa langsung membuka detailnya. Contoh menyusun notifikasi ke grup chat ada di notifikasi pesanan baru ke grup Telegram dengan n8n.

Lalu ada node Stop And Error. Node ini menggagalkan eksekusi dengan sengaja pada kondisi yang kamu tentukan, dan kegagalannya ikut memicu error workflow. Gunakan untuk aturan bisnis: total pesanan nol, email pelanggan kosong, atau respons API sukses tetapi isinya tidak sesuai harapan. Tanpa node ini, kasus seperti itu sering lolos sebagai eksekusi "berhasil" padahal hasilnya salah.

Kebiasaan kecil yang membuat workflow lebih tahan

Simpan data eksekusi yang gagal, setidaknya untuk beberapa waktu, agar bisa diperiksa dan dijalankan ulang. Beri nama node yang jelas, karena nama node terakhir muncul di laporan error. "HTTP Request3" tidak membantu siapa pun pada pukul dua pagi.

Bila workflow dipicu webhook, ingat bahwa kegagalan bisa terjadi bahkan sebelum workflow berjalan, misalnya URL salah atau workflow belum aktif. Masalah semacam ini dibahas di webhook n8n tidak jalan, penyebab dan solusinya.

Untuk instance yang menjalankan banyak workflow berat, error juga bisa datang dari server yang kehabisan memori. Retry tidak menolong di situ. Yang perlu dipikirkan adalah pembagian beban, misalnya lewat n8n queue mode dengan worker terpisah.

Ringkasnya

Workflow yang andal bukan workflow yang tidak pernah gagal, melainkan workflow yang gagal dengan cara yang terkendali. Pakai retry untuk gangguan sementara di node yang aman diulang, alirkan item gagal ke cabang error, gagalkan dengan sengaja saat data tidak masuk akal, dan pasang satu error workflow yang melapor ke tim. Dengan empat lapisan itu, kegagalan tidak lagi baru ketahuan dari keluhan pelanggan.