Workflow n8n yang berjalan sendiri pukul dua pagi punya satu kelemahan: kalau gagal, tidak ada yang melihat. Pesan pelanggan tidak terkirim, baris tidak masuk ke spreadsheet, dan Anda baru tahu tiga hari kemudian. Dokumentasi n8n menyediakan beberapa lapis pengaman untuk ini, dan masing-masing menjawab pertanyaan yang berbeda.
Lapis pertama: error workflow
Error workflow adalah workflow terpisah yang berjalan ketika workflow lain gagal. Cara kerjanya: workflow itu harus dimulai dengan node Error Trigger, lalu workflow yang ingin diawasi menunjuknya lewat Options > Settings > Error workflow. Satu error workflow bisa melayani banyak workflow sekaligus, jadi cukup satu "penjaga" yang mengirim pemberitahuan ke tempat yang memang Anda baca.
Data yang diterima Error Trigger cukup untuk memulai penyelidikan: ID dan tautan eksekusi, pesan error beserta stack-nya, node terakhir yang dijalankan, mode eksekusi, serta ID dan nama workflow. Isi pemberitahuan Anda dengan nama workflow, node yang gagal, dan tautan eksekusinya, supaya orang yang menerimanya tidak perlu mencari dari nol.
Ingin mendalaminya lebih terstruktur? Taalenta punya kelas N8N dan AI Integration untuk Membangun Smart Workflow & AI Agent.
Dua catatan dari dokumentasi yang sering terlewat:
- Error Trigger hanya aktif pada eksekusi otomatis yang gagal. Menjalankan workflow secara manual tidak akan memicunya, jadi cara mengujinya adalah dengan membuat kegagalan sungguhan pada eksekusi terjadwal atau webhook.
- Kalau yang gagal adalah trigger-nya sendiri, workflow tidak sempat dieksekusi. Akibatnya objek
execution(termasuk ID dan tautan) tidak ada, dan datanya berisi objektriggerdengan keterangan error. Susun pesan pemberitahuan agar tetap terbaca ketika bagianexecutionkosong.
Lapis kedua: pengaturan di tiap node
Error workflow menangkap kegagalan setelah terjadi. Pengaturan node memutuskan apa yang terjadi saat kegagalan itu muncul. Di tab Settings sebuah node ada dua hal yang layak diperiksa.
Retry On Fail membuat node mencoba lagi ketika gagal. Ini cocok untuk gangguan sesaat, misalnya API yang sedang padat. Untuk API yang membatasi laju permintaan, dokumentasi n8n menyarankan mengisi Wait Between Tries (ms) dengan nilai lebih panjang dari interval batas API-nya; contohnya 1000 ms untuk API yang mengizinkan satu permintaan per detik. Pada node HTTP Request, opsi Batching (Items per Batch dan Batch Interval) membantu mengatur laju sejak awal.
On Error punya tiga pilihan:
- Stop Workflow: seluruh workflow berhenti dan node sesudahnya tidak berjalan.
- Continue: workflow lanjut ke node berikutnya dengan data valid terakhir.
- Continue (using error output): workflow lanjut, dan informasi error dikirim ke node berikutnya sebagai cabang tersendiri.
Pilihan Continue paling berisiko pada workflow yang berujung ke tindakan nyata. Data valid terakhir bisa ikut terkirim ke node sesudahnya, sehingga workflow tampak "sukses" padahal isinya salah. Cabang error output lebih aman karena Anda bisa memutuskan sendiri: catat ke log, kirim peringatan, atau lewati item itu saja.
Lapis ketiga: gagal dengan sengaja
Tidak semua masalah dianggap error oleh n8n. Data kosong, nominal negatif, atau balasan AI yang tidak sesuai format bisa lolos tanpa satu pun node merah. Node Stop And Error memaksa eksekusi gagal pada kondisi yang Anda tentukan, dengan pesan teks atau objek JSON sendiri, lalu hasilnya ikut ditangkap error workflow. Letakkan di cabang "tidak masuk akal" setelah node IF, dan aturan bisnis Anda ikut terawasi.
Urutan pemasangan yang masuk akal
Mulai dari error workflow tunggal yang mengirim pemberitahuan, hubungkan ke workflow yang berjalan otomatis, lalu tinjau node yang memanggil layanan luar untuk menentukan retry dan perilaku On Error. Tambahkan Stop And Error di titik yang menentukan, seperti sebelum pengiriman pesan atau penulisan data. Untuk workflow dengan AI Agent, ini penting karena keluaran model tidak selalu sesuai bentuk yang diharapkan node sesudahnya.