Kembali ke Blog
News

Tutorial n8n #8: Error Handling dan Retry pada Workflow n8n

Tutorial praktis untuk membuat workflow n8n lebih andal dengan error handling, Retry on Fail, jalur error sederhana, logging, alert, dan pengujian skenario berhasil serta gagal.

•
Frendi Triarista
Tutorial n8n #8: Error Handling dan Retry pada Workflow n8n
n8nworkflow automationerror handlingretrytutorial n8nautomation

Tutorial n8n #8: Error Handling dan Retry pada Workflow n8n

Workflow otomatis tidak cukup hanya bisa berjalan saat semua kondisi ideal. Dalam praktiknya, API bisa lambat, endpoint bisa mengembalikan error sementara, input bisa salah, atau konfigurasi node belum tepat.

Di tutorial #8 ini, kita akan menambahkan reliability secara bertahap pada workflow n8n. Fokusnya bukan membuat sistem enterprise yang rumit, tetapi membuat workflow yang gagal dengan cara yang dapat dipahami.

Menurut saya, reliability dimulai dari membedakan error sementara dan error permanen. Menambah retry tanpa batas justru bisa membuat masalah semakin sulit dilacak.

Prasyarat

Sebelum mengikuti tutorial ini, pastikan Anda sudah memahami:

  1. Dasar workflow n8n.
  2. HTTP Request node.
  3. IF node atau konsep percabangan sederhana.
  4. n8n sudah berjalan.

Tutorial ini tidak membutuhkan credential eksternal.

Gambaran Workflow

Workflow yang akan kita buat:

Manual Trigger -> HTTP Request -> jalur berhasil dan jalur error

Kita akan menggunakan endpoint publik untuk simulasi:

  • Skenario berhasil: https://httpbin.org/status/200
  • Skenario gagal: https://httpbin.org/status/500

Catatan: endpoint publik bisa berubah perilakunya sewaktu-waktu. Jika endpoint tidak tersedia, gunakan endpoint testing lain yang Anda percaya dengan pola status code serupa.

1. Pahami Jenis Error Sebelum Menambahkan Retry

Sebelum mengaktifkan retry, pisahkan dulu jenis error yang mungkin terjadi.

Error yang dapat dicoba ulang

Ini biasanya error sementara. Contohnya:

  • HTTP 500 dari server tujuan.
  • HTTP 502 atau 503.
  • Timeout.
  • Rate limit seperti HTTP 429, dengan catatan perlu memperhatikan batas API.

Untuk error seperti ini, retry masuk akal, tetapi tetap harus dibatasi.

Error input

Ini terjadi karena data yang dikirim tidak valid. Contohnya:

  • HTTP 400 karena payload salah.
  • Field wajib kosong.
  • Format tanggal tidak sesuai.

Retry biasanya tidak menyelesaikan error input. Jika datanya tetap sama, hasilnya kemungkinan tetap gagal.

Error konfigurasi

Ini terjadi karena setting node, URL, method, atau credential salah. Contohnya:

  • URL endpoint salah.
  • Method seharusnya POST, tetapi diset GET.
  • Header authorization belum diisi.
  • Credential tidak valid.

Retry juga tidak menyelesaikan error konfigurasi. Yang perlu dilakukan adalah memperbaiki workflow atau credential.

2. Buat Workflow Dasar

Ikuti langkah berikut:

  1. Buat workflow baru di n8n.
  2. Tambahkan node Manual Trigger.
  3. Tambahkan node HTTP Request setelah Manual Trigger.
  4. Pada HTTP Request, isi konfigurasi awal:
    • Method: GET
    • URL: https://httpbin.org/status/200
    • Authentication: tidak perlu
  5. Simpan workflow.
  6. Jalankan workflow secara manual.

Expected result

HTTP Request berhasil dieksekusi. Karena endpoint mengembalikan status 200, workflow seharusnya selesai tanpa masuk jalur error.

3. Aktifkan Retry on Fail Secara Konservatif

Pada node HTTP Request, buka bagian pengaturan node. Di beberapa versi n8n, pengaturan ini berada di tab atau panel Settings.

Aktifkan retry dengan konfigurasi konservatif:

  1. Retry On Fail: aktif.
  2. Max Tries: 2 atau 3.
  3. Wait Between Tries: 1000 sampai 3000 ms.

Saya biasanya mulai dari angka kecil. Tujuannya adalah memberi kesempatan pada error sementara untuk pulih, bukan menekan service tujuan berulang kali.

Kenapa tidak retry besar?

Retry besar bisa menyebabkan:

  • Workflow berjalan terlalu lama.
  • API tujuan terkena beban tambahan.
  • Rate limit lebih cepat tercapai.
  • Error asli lebih sulit dianalisis.

Retry otomatis tidak menyelesaikan semua error. Retry hanya membantu jika penyebab gagalnya bersifat sementara.

4. Atur On Error Behavior

Secara umum, jika sebuah node gagal dan tidak ada pengaturan khusus, workflow akan berhenti. Ini perilaku yang aman karena error tidak disembunyikan.

Namun untuk workflow tertentu, kita ingin menangani error dengan jalur khusus. Pada node HTTP Request, cari pengaturan On Error.

Pilihan yang umum ditemui:

  1. Stop Workflow

    • Workflow berhenti saat node gagal.
    • Cocok untuk error yang harus langsung menghentikan proses.

  2. Continue atau Continue using default output

    • Workflow tetap lanjut meskipun node error.
    • Cocok jika node berikutnya memang dirancang untuk membaca data error.

  3. Continue using error output

    • Node menyediakan jalur output khusus untuk error.
    • Ini paling mudah dipahami untuk tutorial ini karena jalur berhasil dan jalur error terlihat jelas.

Nama opsi bisa sedikit berbeda tergantung versi n8n, tetapi konsepnya sama: apakah workflow berhenti, lanjut di output biasa, atau lanjut melalui output error.

Untuk tutorial ini, gunakan:

  • On Error: Continue using error output

5. Buat Jalur Berhasil dan Jalur Error

Setelah On Error diatur ke error output, HTTP Request dapat memiliki jalur berhasil dan jalur error.

Buat struktur sederhana:

Manual Trigger
  -> HTTP Request
      -> jalur berhasil: Edit Fields atau No Operation
      -> jalur error: Edit Fields atau No Operation

Untuk jalur berhasil, tambahkan node Edit Fields atau Set dengan field sederhana:

  • status: success
  • message: Request berhasil

Untuk jalur error, tambahkan node Edit Fields atau Set dengan field sederhana:

  • status: failed
  • message: Request gagal dan masuk jalur error

Jangan mengarang data error yang tidak ada. Jika ingin menyimpan detail error, ambil dari output error yang benar-benar tersedia di eksekusi n8n Anda. Struktur data error dapat berbeda tergantung node, jenis error, dan versi n8n.

Jika versi n8n Anda tidak menampilkan error output, gunakan pendekatan alternatif:

  1. Set On Error agar workflow tetap lanjut.
  2. Tambahkan IF node setelah HTTP Request.
  3. Periksa field error yang benar-benar muncul pada output eksekusi.
  4. Arahkan data ke jalur success atau failed berdasarkan field tersebut.

Prinsipnya tetap sama: percabangan harus berdasarkan data nyata dari eksekusi, bukan asumsi.

6. Uji Skenario Berhasil

Gunakan URL berikut pada HTTP Request:

https://httpbin.org/status/200

Jalankan workflow.

Expected result

  1. HTTP Request berhasil.
  2. Retry tidak diperlukan.
  3. Workflow masuk ke jalur berhasil.
  4. Node success menghasilkan status success.

Jika workflow masuk jalur error, cek kembali URL, koneksi internet, dan konfigurasi HTTP Request.

7. Uji Skenario Gagal dengan Aman

Ganti URL HTTP Request menjadi:

https://httpbin.org/status/500

Jalankan workflow.

Expected result

  1. HTTP Request menerima response error dari endpoint.
  2. n8n mencoba ulang sesuai konfigurasi Retry on Fail.
  3. Setelah batas retry tercapai, node masuk jalur error.
  4. Workflow tidak berhenti mendadak jika On Error menggunakan error output.
  5. Node error menghasilkan status failed.

Ini adalah skenario gagal yang aman karena kita hanya memanggil endpoint testing tanpa credential dan tanpa mengubah data di sistem produksi.

8. Kapan Workflow Harus Berhenti?

Tidak semua error perlu ditangani dengan cara lanjut terus.

Workflow sebaiknya berhenti jika:

  1. Error menunjukkan konfigurasi salah.
  2. Data penting tidak valid.
  3. Lanjut eksekusi bisa menyebabkan data ganda atau data rusak.
  4. Node berikutnya bergantung penuh pada hasil node yang gagal.

Workflow boleh lanjut ke jalur error jika:

  1. Anda ingin mencatat kegagalan.
  2. Anda ingin mengirim alert.
  3. Anda ingin menyimpan item gagal untuk diproses ulang nanti.
  4. Anda ingin memberi response yang lebih jelas ke sistem pemanggil.

Untuk proses otomatis, gagal dengan jelas lebih baik daripada terlihat sukses tetapi diam-diam kehilangan data.

9. Logging, Alert, Idempotency, dan Batas Retry

Beberapa praktik sederhana yang sebaiknya mulai dibiasakan:

Logging

Simpan informasi penting dari kegagalan, misalnya:

  • Nama workflow.
  • Node yang gagal.
  • Waktu eksekusi.
  • URL atau operasi yang dipanggil.
  • Pesan error yang tersedia.

Untuk tahap dasar, Anda bisa melihatnya dari halaman executions n8n. Pada tahap lanjutan, logging bisa dikirim ke database atau log service.

Alert

Untuk workflow penting, kirim notifikasi saat error terjadi. n8n juga mendukung error workflow yang dimulai dengan Error Trigger. Error workflow dapat dipasang dari pengaturan workflow agar berjalan saat workflow utama gagal.

Contoh alert sederhana:

  • Email ke admin.
  • Pesan ke Slack atau Telegram.
  • Menulis log ke spreadsheet atau database.

Pada tutorial ini kita belum membangun alert eksternal agar tetap fokus pada konsep dasar.

Idempotency

Idempotency berarti proses bisa dicoba ulang tanpa menyebabkan efek samping ganda.

Contoh masalah:

  • Retry membuat order terkirim dua kali.
  • Retry membuat invoice ganda.
  • Retry mengirim email yang sama berkali-kali.

Sebelum mengaktifkan retry pada operasi yang mengubah data, pikirkan cara mencegah duplikasi. Misalnya dengan external ID, unique key, atau pengecekan status sebelum membuat data baru.

Batas retry

Selalu batasi retry. Untuk tahap awal, gunakan 2 sampai 3 percobaan. Jika masih gagal, arahkan ke jalur error dan catat penyebabnya.

Retry tanpa batas bukan reliability. Itu hanya memindahkan masalah ke tempat lain.

10. Ringkasan Konfigurasi yang Direkomendasikan

Untuk workflow tutorial ini, gunakan konfigurasi berikut:

  1. HTTP Request Method: GET.
  2. URL berhasil: https://httpbin.org/status/200.
  3. URL gagal: https://httpbin.org/status/500.
  4. Retry On Fail: aktif.
  5. Max Tries: 2 atau 3.
  6. Wait Between Tries: 1000 sampai 3000 ms.
  7. On Error: Continue using error output jika tersedia.
  8. Jalur berhasil: tandai status success.
  9. Jalur error: tandai status failed dan simpan detail error yang benar-benar tersedia.

Penutup

Tutorial #8 ini menutup tahap dasar seri n8n. Sampai titik ini, kita sudah menyentuh fondasi workflow, HTTP Request, Webhook, Merge, Code node, dan sekarang error handling serta retry.

Tahap berikutnya bisa membahas topik yang lebih spesifik secara terpisah, seperti credential, database, approval flow, dan observability. Semua itu penting, tetapi fondasinya tetap sama: workflow otomatis harus bisa berhasil dengan jelas dan gagal dengan cara yang mudah dipahami.

Referensi

  1. Handle errors gracefully, n8n Docs, https://docs.n8n.io/flow-logic/error-handling/. Tanggal publish/update sumber: tidak terverifikasi. Diakses pada 22 Agustus 2026.
  2. HTTP Request node, n8n Docs, https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/. Tanggal publish/update sumber: tidak terverifikasi. Diakses pada 22 Agustus 2026.