Error Handling ใน n8n: จัดการ Error อย่างมืออาชีพ

ลองนึกภาพ Workflow ที่ทำงานทุกคืนตี 2 เพื่อ sync ข้อมูลจาก API ภายนอก แล้ววันหนึ่ง API ปลายทาง Timeout ครั้งเดียว — Workflow หยุดทำงาน ข้อมูลไม่ถูก sync แต่คุณไม่รู้เรื่องเลยจนกว่าลูกค้าจะโทรมาถามว่าทำไมข้อมูลไม่อัปเดต

นี่คือปัญหาที่เกิดขึ้นจริงเมื่อ Workflow ไม่มี Error Handling ที่ดี บทความนี้จะสอนวิธีป้องกันและจัดการ Error ใน n8n อย่างครอบคลุม

ทำความเข้าใจ Error ใน n8n

เมื่อ Node ใดใน Workflow เกิด Error n8n จะหยุดการทำงานของ Workflow นั้นทันที และบันทึกสถานะว่า “Error” ไว้ใน Execution History ถ้าไม่มีการตั้งค่า Error Handling ไว้เลย ผลที่ได้คือ:

งานที่ค้างอยู่ไม่ถูกทำต่อ
ไม่มีใครได้รับแจ้ง
ต้องเข้าไปดู Execution Log เองจึงจะรู้ว่ามีปัญหา

n8n มีกลไก Error Handling สองระดับที่ทำงานร่วมกัน — Workflow-level ผ่าน Error Trigger และ Node-level ผ่าน Try/Catch

Error Trigger: แจ้งเตือนเมื่อ Workflow พัง

Error Trigger คือ Node พิเศษที่ใช้สร้าง “Error Workflow” — Workflow ที่ทำหน้าที่รับแจ้งเมื่อ Workflow อื่นเกิด Error

ขั้นตอนการตั้งค่า:

สร้าง Workflow ใหม่ขึ้นมาแยกต่างหาก (เช่น ชื่อว่า “Error Notifier”)
เพิ่ม Error Trigger เป็น Node แรก
ต่อ Node ที่ต้องการ เช่น ส่งอีเมล, ส่ง LINE, หรือโพสต์ใน Slack
ไปที่ Workflow ที่ต้องการป้องกัน → Settings → Error Workflow → เลือก “Error Notifier”

ข้อมูลที่ Error Trigger ส่งมาให้ใช้งาน:

{
  "execution": {
    "id": "12345",
    "url": "https://your-n8n.com/workflow/executions/12345",
    "retryOf": null,
    "error": {
      "message": "Request failed with status code 429",
      "stack": "...",
      "node": {
        "name": "Fetch Orders",
        "type": "n8n-nodes-base.httpRequest"
      }
    },
    "lastNodeExecuted": "Fetch Orders"
  },
  "workflow": {
    "id": "67",
    "name": "Daily Order Sync"
  }
}

ใช้ Expression {{ $json.execution.error.message }} และ {{ $json.workflow.name }} ในข้อความแจ้งเตือนเพื่อให้รู้ทันทีว่า Workflow ไหน Error อะไร

ตัวอย่างข้อความแจ้งเตือนที่ดี:

[n8n Error] {{ $json.workflow.name }}
Node: {{ $json.execution.error.node.name }}
Error: {{ $json.execution.error.message }}
ดู Execution: {{ $json.execution.url }}

Try/Catch: จัดการ Error ในระดับ Node

Error Trigger ดีสำหรับการแจ้งเตือน แต่บางครั้งเราต้องการ “จัดการ” Error ไม่ใช่แค่รับรู้ เช่น ถ้า API หนึ่งล้มเหลวให้ลอง fallback กับ API อื่น หรือถ้า Node หนึ่ง Error ให้บันทึก log แล้วทำงานต่อ

n8n รองรับสิ่งนี้ผ่าน Error Output ของ Node — เปิดใช้ได้โดยคลิกที่ Node → Settings → เปิด “Continue On Fail”

เมื่อเปิด Continue On Fail Node จะมี Output สองเส้น:

Success — ข้อมูลที่ประมวลผลสำเร็จ
Error — ข้อมูล Error ที่เกิดขึ้น พร้อม error message และ item ที่มีปัญหา

ต่อ Error Output ไปยัง Node ที่จะจัดการ เช่น:

HTTP Request Node
  ├── Success → ประมวลผลต่อ
  └── Error → IF Node (ตรวจสอบประเภท Error)
                  ├── 429 Rate Limit → Wait Node → กลับมาลองใหม่
                  ├── 404 Not Found → บันทึก log ว่า record ไม่พบ
                  └── อื่นๆ → ส่งแจ้งเตือนทันที

ตั้งค่า Retry อัตโนมัติ

สำหรับ Error ที่เกิดจากปัญหาชั่วคราว เช่น Network Timeout หรือ Rate Limit การ Retry อัตโนมัติช่วยได้มาก

n8n มี Retry ในระดับ Workflow: ไปที่ Settings → Error Handling → เปิด “Retry On Fail” และตั้งค่า:

Max Tries — จำนวนครั้งสูงสุดที่จะลองซ้ำ (แนะนำ 3)
Wait Between Tries — เวลารอระหว่างการลองซ้ำ (แนะนำ 30-60 วินาที)

สำหรับ HTTP Request Node โดยเฉพาะ มีตัวเลือก Retry ในระดับ Node เพิ่มเติมอีกด้วย

ตั้งค่า Timeout

Workflow ที่ไม่มี Timeout อาจค้างอยู่นานหลายชั่วโมงโดยไม่มีใครรู้ ตั้งค่า Timeout ที่: Settings → Timeout → ใส่เวลาเป็นนาที

แนะนำให้ตั้ง Timeout ให้นานกว่าเวลาทำงานปกติประมาณ 2-3 เท่า เช่น ถ้า Workflow ปกติทำงานใน 5 นาที ตั้ง Timeout ที่ 15 นาที

บันทึก Error Log ลงฐานข้อมูล

สำหรับระบบที่ต้องการ Audit Trail แนะนำให้บันทึก Error ทุกตัวลง Google Sheets หรือฐานข้อมูล โดย Error Workflow ควรมีโครงสร้างดังนี้:

Error Trigger
  → Code Node (จัดรูปแบบข้อมูล Error)
  → Google Sheets (บันทึก log)
  → Slack/LINE (แจ้งเตือนทีม)

ข้อมูลที่ควรบันทึก: timestamp, workflow name, execution ID, node name, error message, execution URL

Pattern: Dead Letter Queue

ในระบบ Message Queue มีแนวคิดเรียกว่า Dead Letter Queue — Message ที่ประมวลผลไม่ได้จะถูกเก็บไว้แทนที่จะทิ้ง ใน n8n ทำได้โดย:

เมื่อ Error เกิดขึ้น ให้บันทึก item ที่ล้มเหลวลง Google Sheets หรือ DB
สร้าง Workflow อีกตัวที่ทำงานทุกชั่วโมงเพื่อดึง item เหล่านี้มาลองประมวลผลใหม่
ถ้าลองซ้ำแล้วยังล้มเหลวเกิน N ครั้ง ส่งให้ทีมดูด้วยตนเอง

Pattern นี้ทำให้มั่นใจว่าข้อมูลไม่สูญหายแม้ API ปลายทางจะล่มชั่วคราว

Checklist Error Handling สำหรับทุก Workflow

ก่อน Deploy Workflow ใดๆ ให้ตรวจสอบ:

ตั้ง Error Workflow แล้ว
Error Workflow ส่งแจ้งเตือนไปช่องทางที่ทีมเห็น (ไม่ใช่แค่อีเมลที่ไม่มีใครอ่าน)
Node ที่เรียก External API ทุกตัวตั้ง Continue On Fail ไว้
มี Timeout ที่เหมาะสม
ทดสอบว่าเมื่อ Error เกิดขึ้นจริง แจ้งเตือนทำงาน

Error Handling ดูเหมือนงานพิเศษที่เพิ่มขึ้นมา แต่ในความเป็นจริงมันคือส่วนที่ทำให้ Workflow “ใช้งานได้จริง” ในระยะยาว Workflow ที่ไม่มี Error Handling คือ Workflow ที่แค่รอวันพัง

อยากเรียน n8n แบบเป็นระบบ ตั้งแต่เริ่มต้นจนสร้าง Workflow ใช้งานจริงได้ ลองดู คอร์สสอน n8n ที่ aiunlock.co