Error Handling n8n: Bikin Workflow Production Andal

Workflow n8n yang jalan sempurna di laptop lokal sering gagal total di production. Bukan karena logic salah — tapi karena tidak ada error handling yang proper. Satu API timeout, satu rate limit, dan seluruh pipeline diam-diam berhenti tanpa notifikasi. Ini pattern yang gua pakai untuk bikin workflow yang bisa dipercaya.

Kenapa Error Handling di n8n Sering Dianggap Opsional

Saat development, semua node berhasil. API respons normal, data formatnya sesuai, tidak ada timeout. Workflow terasa "selesai". Tapi di production, realita beda:

• API rate limit — server tujuan punya batas request per menit yang tidak lo antisipasi
• Payload tidak konsisten — data yang datang dari webhook atau spreadsheet berbeda formatnya di field tertentu
• Node tersembunyi gagal — node Error Trigger tanpa catch berarti error silently swallowed
• Infinite loop — retry tanpa max attempts bikin workflow eksekusi 1000x dalam 10 menit

Tanpa pattern error handling, lo tidak punya visibility. Workflow "berjalan" tapi outputnya salah atau kosong — dan lo baru tahu setelah klien/report bermasalah.

Error Trigger: Catch Spesifik, Bukan Catch-All

n8n punya Error Trigger node yang menangkap error dari node upstream. Yang sering terjadi: orang pasang satu Error Trigger di ujung workflow dengan konfigurasi "Catch All Errors". Bekerja, tapi terlalu coarse-grained.

Yang lebih baik:

HTTP Request Node
  ↓
  [Error Output] → Switch: status >= 500 → Escalation Path
  [Success]      → Continue normal flow
  [Error Output] → Switch: status == 429 → Retry w/ backoff
  [Error Output] → Switch: timeout       → Notify + log

Pecah error berdasarkan jenis, bukan satu catch umum. HTTP 429 (rate limit) butuh treatment berbeda dari HTTP 500 (server error) atau timeout (network issue).

Retry Logic: Backoff, Max Attempts, Dead Letter

Retry adalah pola dasar, tapi implementasi yang salah bikin masalah baru.

Exponential Backoff

Jangan retry langsung. Pakai exponential backoff: attempt 1 tunggu 5 detik, attempt 2 tunggu 15 detik, attempt 3 tunggu 45 detik. Ini pattern standar industri karena:

• Memberi waktu server target untuk recover
• Menghindari thundering herd (semua retry gleichzeitig)
• Menghemat API quota

Max Attempts

Tetap harus ada batas. Tanpa ini, workflow bisa loop forever jika kondisi error persist. Set 3-5 attempts sudah cukup untuk majority of transient failures.

Dead Letter Pattern

Jika semua retry gagal, jangan biarkan data hilang. Simpan ke:

• Spreadsheet / database dengan timestamp, error message, payload asli
• Email notification khusus untuk failed items
• Queue terpisah (Redis queue, dedicated spreadsheet) untuk manual follow-up

Dead letter bukan failure — ini audit trail. Lo tahu ada X items yang gagal diproses, apa errornya, dan bisa reprocess manual atau investigate.

Alerting: Workflow yang Gagal tapi Tidak Ada yang Tahu

Ini yang paling sering di-skip: workflow gagal tapi tidak ada notifikasi. Setelah 3 jam baru sadar karena klien tanya "kenapa email tidak pernah terkirim?"

Minimum alerting:

Error Trigger
  → Telegram: "Workflow [nama] gagal di [node].
     Error: [detail].
     Payload: [id/reference]."
  → Stop execution

Telegram atau Discord webhook sudah cukup untuk tim kecil. Untuk operasi lebih formal, pakai email dedicated atau PagerDuty-compatible endpoint.

Yang tidak perlu di-alert: setiap retry attempt. Alert hanya saat retry final gagal atau dead letter tercipta. Alert per-retry attempt = noise.

Recovery Pattern: Resume dari Titik Gagal

Tanpa state management, retry selalu restart dari awal. Untuk workflow yang memproses batch 100 items dan gagal di item #87, restart = proses ulang 1-86 yang sudah berhasil. Mahal dan tidak perlu.

Dua pendekatan:

• Checkpointing — simpan state (last processed ID, progress) ke spreadsheet. Jika gagal, baca state terakhir, continue dari sana.
• Idempotent operations — pastikan setiap step aman di-run ulang tanpa duplikasi. Gunakan unique ID atau checksum untuk dedupe.

Untuk pipeline yang memproses data sensitif (financial, compliance), checkpointing lebih aman karena lo punya record persis apa yang sudah diproses dan apa yang belum.

Checklist Validasi Sebelum Workflow ke Production

Sebelum mark workflow "siap production", test ini:

• [ ] Semua API call punya Error Trigger dengan branching spesifik
• [ ] Retry pakai exponential backoff dengan max 3-5 attempts
• [ ] Failed items disimpan ke dead letter (sheet/queue)
• [ ] Alert terkirim ke Telegram/Discord saat dead letter tercipta
• [ ] Workflow idempotent atau punya checkpoint (jika memproses batch)
• [ ] Di-test dengan payload error: API timeout, 429, 500

Workflow yang lulus checklist ini = workflow yang bisa lo percaya berjalan sendiri tanpa perlu di-monitor setiap jam.

Error handling bukan opsional — ini bagian dari arsitektur workflow. Workflow tanpa error handling bukan automation, itu schedule untuk masalah.