Monitoring Eksekusi n8n: Tahu Workflow Gagal Lebih Dulu
Workflow n8n yang gagal jarang berteriak. Biasanya yang pertama tahu justru user: “Kok laporan pagi ini tidak masuk?” atau “Invoice pelanggan kemarin belum terkirim ya?”. Monitoring eksekusi n8n tujuannya membalik urutan itu, supaya Anda tahu ada masalah lebih dulu dan sudah memperbaikinya sebelum ada yang komplain.
Artikel ini membahas apa saja yang perlu dipantau, cara membaca execution log, cara memasang alert untuk workflow yang gagal maupun yang diam-diam tidak jalan, pengaturan retensi data eksekusi, dan cara menyusun dashboard kesehatan workflow sederhana.
Metrik yang perlu dipantau
Tidak perlu memantau semuanya. Untuk kebanyakan tim, lima hal ini sudah menutup sebagian besar masalah:
- Eksekusi gagal. Berapa kali workflow berakhir dengan error, per workflow, per hari.
- Tingkat kegagalan. Persentase eksekusi gagal dibanding total. Satu kali gagal dari 1.000 eksekusi berbeda cerita dengan satu dari tiga.
- Workflow yang tidak jalan. Workflow terjadwal yang seharusnya jalan jam 6 pagi tapi tidak ada eksekusi sama sekali. Ini yang paling sering terlewat, karena tidak ada error yang muncul.
- Durasi eksekusi. Workflow yang biasanya selesai 30 detik tiba-tiba butuh 10 menit. Sering jadi tanda API tujuan melambat atau data membengkak.
- Kesehatan server (kalau self-host): n8n bisa diakses atau tidak, pemakaian memori, dan sisa ruang disk.
Mulailah dari workflow yang dampaknya paling besar kalau gagal, misalnya yang mengirim invoice, memproses order, atau menyinkronkan stok. Workflow eksperimen tidak perlu alert.
Membaca execution log
Setiap kali workflow jalan, n8n mencatat satu eksekusi. Daftarnya bisa dilihat di halaman Executions, baik untuk semua workflow maupun per workflow. Anda bisa memfilter berdasarkan status seperti sukses, error, sedang berjalan, atau menunggu.
Saat membuka satu eksekusi yang gagal, n8n menampilkan workflow dalam kondisi saat itu: node mana yang sudah jalan, data apa yang masuk dan keluar di tiap node, dan node mana yang memunculkan error beserta pesannya.
Beberapa kebiasaan saat membaca log:
- Lihat node pertama yang merah, bukan node terakhir. Error sering berasal dari data yang sudah salah beberapa langkah sebelumnya.
- Cek input node yang gagal. Banyak error ternyata karena kolom kosong, format tanggal berubah, atau aplikasi sumber mengubah nama field.
- Bedakan error sementara dan permanen. Timeout atau error 429 (terlalu banyak request) biasanya hilang kalau dicoba ulang. Error 401 (akses ditolak) berarti kredensial perlu diperbarui.
- Pakai fitur retry dari halaman eksekusi setelah penyebabnya diperbaiki, supaya data yang tertunda tetap terproses.
Satu catatan keamanan: execution log menyimpan data yang lewat di workflow, termasuk data pelanggan. Batasi siapa yang punya akses ke instance n8n Anda.
Alert kegagalan dan workflow macet
Alert saat workflow gagal
Cara bawaan n8n adalah error workflow. Anda membuat satu workflow khusus yang diawali node Error Trigger, lalu memilihnya di pengaturan workflow lain sebagai “Error workflow”. Setiap kali workflow produksi gagal, error workflow ini jalan dan menerima informasi seperti nama workflow, node yang gagal, pesan error, dan link ke eksekusinya.
Dari sana, kirim notifikasi ke tempat yang benar-benar dibaca tim: email, Slack, Telegram, atau WhatsApp. Satu error workflow bisa dipakai bersama oleh banyak workflow. Penjelasan lebih detail soal pola ini ada di error handling di n8n.
Perlu diingat, error workflow tidak berjalan untuk eksekusi manual saat Anda sedang menguji di editor. Jadi uji alurnya dengan eksekusi produksi yang sengaja dibuat gagal.
Alert saat workflow macet atau tidak jalan
Error workflow hanya jalan kalau ada error. Dua kasus berikut lolos dari pantauannya:
- Workflow menggantung. Misalnya menunggu respons API yang tidak pernah datang. Pasang batas waktu (timeout) di pengaturan workflow. Di versi self-host, batas default untuk semua workflow bisa diatur lewat variabel
EXECUTIONS_TIMEOUT, yang secara bawaan tidak aktif. - Workflow tidak terpicu sama sekali. Misalnya workflow tidak sengaja dinonaktifkan, server mati saat jadwalnya, atau webhook dari aplikasi lain berhenti mengirim data.
Untuk kasus kedua, pakai pola “absen harian”: buat workflow pemantau yang jalan setiap pagi, mengambil daftar eksekusi terakhir dari workflow penting (lewat node n8n atau API publik n8n), lalu mengecek apakah ada eksekusi sukses dalam rentang waktu yang diharapkan. Kalau tidak ada, kirim alert.
Contoh aturan sederhana:
| Workflow | Harus ada eksekusi sukses | Alert kalau tidak ada |
|---|---|---|
| Laporan harian penjualan | Setiap hari sebelum jam 07.00 | Jam 07.15 ke admin |
| Sinkron stok | Minimal sekali per jam | Setelah 2 jam kosong |
| Terima order dari website | Minimal 1 per hari kerja | Jam 14.00 ke tim ops |
Untuk self-host, pantau juga server-nya dari luar. n8n menyediakan endpoint health check (secara default di /healthz) yang bisa dicek oleh layanan uptime monitoring. Kalau n8n mati, workflow pemantau di dalam n8n tentu ikut mati, jadi pemeriksaan dari luar tetap perlu.
Retensi data eksekusi
Setiap eksekusi yang disimpan memakan ruang database. Kalau workflow Anda jalan ribuan kali sehari, database bisa membengkak dan n8n melambat.
Di n8n self-hosted, pembersihan data eksekusi lama sudah aktif secara default. Menurut dokumentasi resmi n8n, pengaturan bawaannya adalah:
EXECUTIONS_DATA_PRUNE=true: data eksekusi lama dihapus bertahap.EXECUTIONS_DATA_MAX_AGE=336: eksekusi berumur lebih dari 336 jam (14 hari) dihapus.EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000: maksimal 10.000 eksekusi disimpan.
Anda juga bisa memilih untuk tidak menyimpan data eksekusi yang sukses (EXECUTIONS_DATA_SAVE_ON_SUCCESS=none) dan hanya menyimpan yang gagal. Ini menghemat ruang, tapi Anda kehilangan jejak untuk menelusuri kasus “sukses tapi hasilnya salah”. Untuk workflow keuangan, biasanya lebih aman tetap menyimpan keduanya dengan umur yang wajar.
Di n8n Cloud, lama penyimpanan data eksekusi tergantung paket. Cek halaman harga dan dokumentasi resmi untuk angka terbaru, karena ketentuannya bisa berubah. Perbandingan umum kedua versi dibahas di n8n self hosted vs cloud.
Kalau Anda butuh riwayat lebih panjang untuk audit, jangan mengandalkan execution log. Catat ringkasan tiap eksekusi penting (waktu, status, jumlah data diproses) ke database atau spreadsheet terpisah.
Dashboard kesehatan workflow
Setelah alert berjalan, langkah berikutnya adalah melihat tren. Beberapa pilihan, dari yang paling mudah:
Insights bawaan n8n. n8n menampilkan ringkasan 7 hari terakhir di semua paket: jumlah eksekusi produksi, eksekusi gagal, tingkat kegagalan, rata-rata durasi, dan perkiraan waktu yang dihemat. Dashboard Insights yang lebih lengkap tersedia di paket berbayar tertentu (per Oktober 2026, Cloud Pro dan Enterprise, serta self-hosted Business dan Enterprise). Eksekusi manual dan sub-workflow tidak ikut dihitung.
Log ringkasan sendiri. Tambahkan satu langkah di akhir workflow penting yang mencatat status ke tabel, lalu tampilkan di Looker Studio atau Metabase. Cara ini gratis dan fleksibel.
Prometheus dan Grafana untuk self-host. n8n bisa membuka endpoint /metrics dengan mengaktifkan N8N_METRICS=true. Data ini bisa ditarik Prometheus dan divisualkan di Grafana. Dokumentasi n8n mengingatkan agar endpoint ini tidak dibuka ke internet publik. Pilihan ini cocok kalau tim Anda sudah memakai kedua tools tersebut. Kalau n8n Anda berjalan di VPS, lihat juga hosting n8n di VPS untuk urusan spesifikasi server.
Isi dashboard yang berguna biasanya sederhana: daftar workflow penting dengan status terakhir, jumlah gagal 7 hari terakhir, tren durasi, dan workflow yang tidak jalan sesuai jadwal.
Kalau workflow n8n sudah jadi bagian penting operasional tapi belum ada yang memantau, Aqilatic bisa membantu memasang alert dan dashboard kesehatannya, atau merawat workflow Anda secara rutin. Lihat layanan kami, atau mulai dengan audit proses gratis.
Pertanyaan yang sering muncul
Apakah n8n Cloud sudah punya monitoring bawaan?
Ada halaman Executions untuk melihat riwayat dan ringkasan Insights 7 hari di semua paket. Alert tetap perlu Anda pasang sendiri lewat error workflow.
Berapa banyak alert yang ideal?
Sesedikit mungkin tapi selalu ditindaklanjuti. Kalau tim mulai mengabaikan alert karena terlalu sering, gabungkan alert kecil ke ringkasan harian dan sisakan alert langsung untuk workflow yang kritis.
Apakah retensi 14 hari cukup?
Untuk menelusuri error, biasanya cukup. Untuk keperluan audit atau pembuktian ke pelanggan, simpan ringkasan eksekusi penting di tempat terpisah dengan umur yang lebih panjang.