Workflow n8n Gagal Bukan Berarti Selesai: Rancang Jalur Fallback yang Bisa Dipulihkan

Workflow otomatis sering terlihat baik-baik saja sampai satu layanan di tengah proses mengalami gangguan. API pembayaran lambat, CRM menolak permintaan, atau server tujuan mengembalikan status 500. Jika workflow langsung berhenti tanpa konteks, masalah kecil bisa berubah menjadi pekerjaan manual yang panjang.

Solusinya bukan selalu menambah lebih banyak node. Yang lebih penting adalah merancang workflow agar tahu apa yang harus dilakukan ketika sebuah langkah gagal: mencoba lagi, menunggu, meneruskan ke jalur alternatif, atau berhenti dengan pesan yang jelas.

Kenali dulu jenis kegagalannya

Tidak semua error layak dicoba ulang. Secara praktis, kegagalan dalam integrasi API bisa dibagi menjadi dua kelompok.

• Error sementara: koneksi timeout, layanan sedang sibuk, atau server mengembalikan status 502 dan 503. Dalam kondisi seperti ini, percobaan ulang setelah jeda sering masuk akal.
• Error permanen: API key tidak valid, format data salah, endpoint sudah berubah, atau akun tidak memiliki izin. Mengulang permintaan berkali-kali hanya membuang waktu dan bisa memperburuk masalah.

Pembedaan ini adalah bagian dari desain workflow, bukan pekerjaan yang sebaiknya dilakukan setelah semuanya gagal. Dalam n8n, HTTP Request dapat dikonfigurasi untuk mengembalikan status dan header respons. Dengan begitu, workflow bisa memeriksa kode respons sebelum menentukan langkah berikutnya.

Jadikan respons API sebagai data yang bisa diperiksa

Pada node HTTP Request, aktifkan opsi Include Response Headers and Status jika Anda perlu membaca kode status dari layanan tujuan. Opsi Never Error juga dapat digunakan ketika Anda ingin respons non-2xx masuk ke alur berikutnya sebagai data, bukan langsung menghentikan eksekusi.

Contoh alur sederhananya:

1. HTTP Request: kirim data ke API.
2. IF atau Switch: periksa $json.statusCode atau struktur respons yang dikembalikan.
3. Jalur sukses: simpan ID transaksi atau tandai pekerjaan sebagai selesai.
4. Jalur gagal: klasifikasikan error dan tentukan apakah perlu menunggu, mencoba lagi, atau meminta pemeriksaan manual.

Nama field dapat berbeda tergantung konfigurasi node dan bentuk data yang digunakan. Karena itu, jalankan satu permintaan uji terlebih dahulu dan lihat struktur output aktualnya sebelum membuat kondisi.

Gunakan jeda, bukan percobaan ulang bertubi-tubi

Ketika layanan sedang lambat, mengirim lima permintaan dalam waktu hampir bersamaan bukan pemulihan. Itu justru bisa menambah beban pada layanan tujuan dan membuat workflow semakin sulit dilacak.

Gunakan Wait node untuk memberi jeda sebelum percobaan ulang. Node ini dapat menunda eksekusi berdasarkan interval waktu tertentu, lalu melanjutkannya ketika waktunya tiba. Data eksekusi disimpan dan dimuat kembali saat workflow dilanjutkan.

Untuk kasus sederhana, Anda bisa memakai pola seperti ini:

1. Percobaan pertama gagal dengan status sementara.
2. Tunggu 30 detik.
3. Coba kembali satu kali.
4. Jika masih gagal, tunggu 5 menit.
5. Jika tetap gagal, pindahkan pekerjaan ke jalur pemeriksaan manual.

Jangan membuat workflow mencoba ulang tanpa batas. Tetapkan jumlah maksimum percobaan dan simpan nilai penghitung, misalnya retryCount, di dalam item data. Tanpa batas yang jelas, satu gangguan kecil bisa menciptakan eksekusi yang berjalan terlalu lama atau mengulang permintaan secara tidak terkendali.

Bedakan kegagalan teknis dan kegagalan bisnis

Contoh yang sering membingungkan adalah API mengembalikan respons HTTP 200, tetapi isi datanya menyatakan transaksi ditolak. Dari sisi jaringan, permintaan berhasil. Dari sisi bisnis, pekerjaan gagal.

Karena itu, jangan hanya memeriksa kode HTTP. Periksa juga field penting dari respons, misalnya:

• success atau status dari layanan tujuan.
• ID transaksi yang wajib ada setelah operasi berhasil.
• Pesan validasi seperti alamat email tidak sah atau stok tidak tersedia.
• Nilai yang menunjukkan apakah permintaan aman untuk diulang.

Error teknis biasanya layak dipertimbangkan untuk dicoba ulang. Error validasi bisnis biasanya harus diperbaiki datanya atau ditinjau manusia. Ini adalah penilaian desain, bukan aturan mutlak; setiap API memiliki perilaku dan dokumentasi yang berbeda.

Buat jalur gagal yang tetap menghasilkan informasi

Workflow yang gagal tanpa catatan akan memaksa Anda membuka eksekusi satu per satu. Minimal, simpan informasi berikut ketika sebuah langkah tidak berhasil:

• waktu kejadian;
• nama workflow;
• nama node yang gagal;
• kode status dan pesan dari API;
• ID data atau transaksi yang sedang diproses;
• jumlah percobaan yang sudah dilakukan;
• status akhir: akan dicoba ulang, menunggu tindakan, atau gagal permanen.

Tempat penyimpanannya bisa berupa database, Data Table, Google Sheets, atau sistem tiket internal. Yang penting, catatan tersebut dapat dicari berdasarkan ID transaksi. Hindari menyimpan token akses, password, atau seluruh payload mentah jika di dalamnya ada data sensitif.

Kapan memakai Error Trigger?

Jalur pemeriksaan status cocok untuk error yang memang Anda antisipasi. Namun, workflow juga perlu menangani error yang tidak terduga, seperti node salah konfigurasi atau masalah infrastruktur. Untuk itu, n8n menyediakan Error Trigger sebagai awal dari error workflow.

Error workflow dapat dipakai untuk mengirim notifikasi ke email atau Slack, mencatat nama workflow, URL eksekusi, node terakhir yang dijalankan, dan pesan error. Satu error workflow juga dapat digunakan oleh beberapa workflow, sehingga pola pemberitahuan lebih konsisten.

Jika ada kondisi tertentu yang menurut Anda harus dianggap sebagai kegagalan, gunakan Stop And Error. Node ini memungkinkan workflow dihentikan dengan pesan atau objek error buatan sendiri. Contohnya, setelah tiga kali percobaan ulang gagal, workflow dapat dihentikan dengan pesan yang menyertakan ID transaksi dan alasan terakhir.

Yang bisa dilakukan sekarang

1. Pilih satu workflow yang paling sering memanggil API eksternal.
2. Aktifkan pengembalian status respons pada node HTTP Request.
3. Buat kondisi terpisah untuk sukses, error sementara, dan error permanen.
4. Tambahkan Wait node dengan maksimum dua atau tiga percobaan ulang.
5. Simpan ID data, pesan error, dan jumlah percobaan.
6. Buat error workflow sederhana untuk mengirim notifikasi ketika eksekusi benar-benar gagal.
7. Uji skenario timeout, respons 500, data tidak valid, dan respons sukses palsu seperti HTTP 200 dengan status bisnis gagal.

Otomasi yang matang bukan workflow yang tidak pernah gagal. Itu hampir tidak mungkin jika workflow bergantung pada banyak layanan. Otomasi yang matang adalah workflow yang gagal dengan cara yang bisa dipahami, tidak mengulang tindakan secara membabi buta, dan memberi jalan yang jelas untuk dipulihkan.

Sumber & bacaan lebih lanjut

• n8n HTTP Request node documentation
• n8n Wait node documentation
• n8n Handle errors gracefully
• n8n Stop And Error node documentation

– Rio Yotto @rioyotto