10 lỗi n8n khiến workflow ‘đơ’ và cách sửa triệt để từ chuyên gia

n8n workflow bị đơ thường do lỗi timeout kết nối API, cấu hình sai Execution Timeout, hoặc dùng node Webhook sai cách. Bí quyết sửa là: set thời gian chờ tối thiểu 60 giây, dùng node “Wait” để tránh quá tải, và kiểm tra log lỗi trong tab “Execution” trước.

Anh em SME đang chạy n8n để tự động hóa, bỗng một ngày workflow “đơ” như con ngựa gỗ? Cảm giác đó chán vãi. Bạn đặt lịch email marketing, nó chạy được vài lần rồi dừng. Hoặc tệ hơn: chạy ngon lành tới bước gửi dữ liệu lên Google Sheets thì treo luôn. Thực tế mà nói, không phải do n8n dở, mà do bạn đang mắc mấy lỗi cơ bản mà cao thủ nào cũng từng dính.

Cái này mới quan trọng này: Năm 2026, n8n đã có bản cập nhật mới với tính năng “Error Workflow” riêng, nhưng 80% anh em vẫn không biết dùng. Họ cứ cắm đầu chạy, rồi đổ thừa tool. Đừng thế. Mình sẽ chỉ ra lỗi số 1 ngay bây giờ.

Lỗi số 1: Quên cài Execution Timeout – Workflow chạy mãi không dứt

Bạn có một workflow lấy dữ liệu từ 500 đơn hàng trên Shopify, gọi qua 3 API khác nhau. Nếu không set “Execution Timeout” (mặc định là 0 – không giới hạn), gặp API chậm, workflow sẽ treo vô thời hạn. Kết quả là: nó chiếm RAM, CPU, và làm các workflow khác chết theo.

Cách sửa triệt để:

• Vào Settings → Workflow → Execution Timeout. Đặt tối thiểu 60 giây cho workflow đơn giản, 300 giây cho workflow phức tạp.
• Dùng node “Split In Batches” nếu phải xử lý nhiều item. Ví dụ: chia 500 đơn thành 10 batch, mỗi batch 50 đơn, chạy tuần tự. Làm luôn nhé, đừng tham.

Lỗi số 2: Webhook node không có response – API partner không biết gửi gì

Anh em hay dùng Webhook node để nhận dữ liệu từ bên ngoài (ví dụ: từ form Typeform). Nhưng quên mất một điều: mỗi khi Webhook nhận request, nó phải trả về một response HTTP (200 OK) để báo “đã nhận”. Nếu không, bên gửi sẽ timeout và gửi lại, gây ra hàng loạt bản ghi trùng.

Cách sửa:

• Ngay sau node Webhook, thêm node “Respond to Webhook”. Trong đó, set status code là 200, body có thể để trống hoặc gửi “success”.
• Kiểm tra log: vào Execution → xem dòng “Webhook node” có báo “error” không. Nếu có, thường là do thiếu response.

Lỗi số 3: Dùng HTTP Request node sai method – Gửi POST thành GET

Lỗi này ngớ ngẩn nhưng phổ biến. Bạn muốn gửi dữ liệu lên API, nhưng để nhầm method thành GET. API trả về lỗi 405 Method Not Allowed, workflow dừng ngay. Hoặc tệ hơn, nó chạy nhưng gửi sai dữ liệu.

Cách sửa:

• Trong node HTTP Request, kiểm tra kỹ “Method” (GET, POST, PUT, DELETE). Nếu là gửi dữ liệu mới, dùng POST. Nếu cập nhật, dùng PUT.
• Dùng tab “Options” để bật “Retry on Fail” – nếu lỗi tạm thời, nó tự chạy lại 3 lần.

Lỗi số 4: Không xử lý lỗi API – Workflow “đơ” vì exception

API bên thứ ba lúc nào cũng có thể trả về lỗi: 429 (Too Many Requests), 500 (Internal Server Error), hoặc 404. Mặc định n8n sẽ dừng workflow nếu gặp lỗi. Điều này khiến toàn bộ quy trình đứt đoạn.

Cách sửa:

• Bật “Continue on Fail” trong node HTTP Request. Nó sẽ cho phép workflow chạy tiếp dù có lỗi.
• Thêm node “IF” sau đó để kiểm tra status code. Nếu là 429, dùng node “Wait” chờ 30 giây rồi retry.
• Dùng “Error Workflow” (tính năng mới 2026): tạo một workflow riêng chỉ để bắt lỗi, gửi thông báo vào Slack hoặc Telegram. Làm luôn nhé, cứu sống đấy.

Điểm hay ở chỗ là: chỉ cần sửa 4 lỗi trên, 70% workflow “đơ” của anh em sẽ chạy ngon. Nhưng còn 6 lỗi nữa cực kỳ nguy hiểm, như lỗi về “Loop” vô hạn, lỗi “Memory Leak” do dùng node “Code” sai, hay lỗi “Timezone” khi lên lịch. Những cái này mình sẽ nói rõ trong phần tiếp theo. Anh em nhớ theo dõi.

Lỗi số 5: Loop vô hạn – Workflow chạy xong lại chạy tiếp

Anh em dùng node “Schedule” (Cron) để chạy workflow mỗi 5 phút. Trong workflow đó, bạn lại có node ghi dữ liệu vào database, rồi dùng node “Webhook” để lắng nghe sự kiện từ chính database đó. Kết quả là: workflow tự gọi chính nó, tạo ra một vòng lặp vô tận. Server ngốn hết RAM, CPU, cuối cùng là crash.

Cách sửa:

• Thêm node “IF” ở đầu workflow để kiểm tra “Nếu dữ liệu này do chính workflow tạo ra thì dừng”. Cách đơn giản: thêm một field “source” với giá trị “n8n” khi ghi dữ liệu, sau đó lọc ra.
• Dùng “Execution ID” để đánh dấu. Mỗi lần chạy, lưu ID vào một biến, nếu phát hiện ID trùng, thoát ngay.
• Bật “Max Execution” trong Settings: giới hạn tối đa 100 lần chạy cho một workflow. Làm luôn nhé, không thì cháy server.

Lỗi số 6: Memory Leak do node “Code” sai cách

Node “Code” cho phép viết JavaScript hoặc Python tùy chỉnh. Nhưng anh em hay quên đóng kết nối, hoặc tạo biến toàn cục không dọn dẹp. Ví dụ: bạn mở một file JSON, đọc xong nhưng không close stream. Mỗi lần workflow chạy, bộ nhớ tăng lên một ít. Sau 1000 lần, server ngập.

Cách sửa:

• Luôn dùng try...catch...finally để đảm bảo đóng tài nguyên. Ví dụ: fs.closeSync(fd) sau khi đọc file.
• Không dùng biến var toàn cục. Dùng let hoặc const trong phạm vi hàm.
• Dùng node “Code” bản mới nhất của n8n 2026 – nó có tính năng tự động garbage collection. Update ngay.

Lỗi số 7: Timezone sai – Workflow lên lịch chạy nhầm giờ

Bạn set workflow chạy lúc 8:00 sáng để gửi email báo cáo. Nhưng n8n server mặc định dùng UTC. 8:00 UTC là 15:00 giờ Việt Nam. Kết quả là: khách hàng nhận email lúc 3 giờ chiều, thay vì sáng sớm. Quá tệ.

Cách sửa:

• Vào Settings → Workflow → Timezone. Chọn “Asia/Ho_Chi_Minh”.
• Hoặc trong node “Schedule”, set cron theo giờ địa phương. Ví dụ: 0 8 * * * cho 8:00 sáng (nếu đã set timezone).
• Kiểm tra bằng cách chạy thử: bấm “Execute Workflow” và xem thời gian trong log. Thực tế mà nói, lỗi này mất 2 phút sửa nhưng cứu cả chiến dịch.

Lỗi số 8: Quá tải node “Wait” – Workflow chờ nhau chết

Bạn dùng node “Wait” để tạm dừng workflow chờ API xử lý. Nhưng nếu có 100 workflow cùng chạy, mỗi cái chờ 30 giây, server sẽ bị nghẽn. Node “Wait” không giải phóng tài nguyên, nó giữ nguyên thread.

Cách sửa:

• Thay node “Wait” bằng node “Polling” kết hợp với “IF”. Ví dụ: cứ 5 giây kiểm tra API một lần, nếu xong thì tiếp, không thì chờ tiếp. Nhưng giới hạn số lần kiểm tra (tối đa 10 lần).
• Dùng “Queue Mode” trong n8n 2026: cho phép workflow chạy bất đồng bộ, không chiếm thread. Bật trong Settings → Execution → Queue Mode.
• Anh em cần lưu ý: node “Wait” chỉ nên dùng cho tác vụ đơn lẻ, không dùng cho batch.

Case Study thực tế: 1988 Media cứu workflow cho khách hàng e-commerce

Tháng 3/2026, một khách hàng của 1988 Media (shop thời trang online) gặp vấn đề: workflow đồng bộ đơn hàng từ Shopify sang hệ thống ERP cứ “đơ” sau 50 đơn. Họ chạy được 2 tuần, rồi mỗi ngày phải restart server thủ công. Mệt mỏi.

Chẩn đoán:

• Lỗi Execution Timeout: workflow set mặc định 0, nên khi API ERP chậm (do server cũ), nó treo mãi.
• Lỗi Webhook response: Webhook từ Shopify nhận đơn, nhưng không trả response, dẫn đến Shopify gửi lại, tạo bản ghi trùng.
• Lỗi Loop: workflow có node ghi log vào Google Sheets, log đó lại kích hoạt workflow khác, tạo vòng lặp.

Giải pháp của 1988 Media:

• Set Execution Timeout = 120 giây. Chia 500 đơn thành 10 batch, mỗi batch 50 đơn.
• Thêm node “Respond to Webhook” ngay sau Webhook node.
• Thêm node “IF” lọc: nếu field “source” = “n8n” thì dừng.
• Dùng “Error Workflow” gửi thông báo vào Telegram nếu có lỗi.

Kết quả là: workflow chạy ổn định 24/7 trong 3 tháng liền, không lần nào “đơ”. Khách hàng tiết kiệm 20 giờ/tháng so với làm thủ công. Cái này mới quan trọng này: họ còn tăng doanh thu 15% nhờ xử lý đơn nhanh hơn.

Bảng so sánh: Các lỗi thường gặp và cách sửa nhanh

Lỗi	Nguyên nhân	Cách sửa nhanh	Mức độ nguy hiểm
Execution Timeout	Không set thời gian chờ	Set 60-300 giây trong Settings	Cao
Webhook thiếu response	Không trả HTTP 200	Thêm node “Respond to Webhook”	Cao
Sai HTTP method	Dùng GET thay POST	Kiểm tra method, bật Retry	Trung bình
Không xử lý lỗi API	Workflow dừng khi gặp lỗi	Bật “Continue on Fail” + Error Workflow	Cao
Loop vô hạn	Workflow tự gọi chính nó	Thêm node IF lọc source	Rất cao
Memory Leak	Không đóng tài nguyên	Dùng try…finally, update n8n	Cao
Timezone sai	Dùng UTC mặc định	Set Asia/Ho_Chi_Minh	Trung bình
Quá tải node Wait	Giữ thread quá lâu	Dùng Queue Mode + Polling	Cao

FAQ – Những câu hỏi anh em hay hỏi

Hỏi: Workflow của tôi chạy ổn, nhưng tự dưng “đơ” sau 2 tuần. Tại sao?
Đáp: Thường do API bên thứ ba thay đổi endpoint, hoặc server hết RAM. Kiểm tra log trong tab “Execution” xem có lỗi 429 hay 500 không. Thêm node “Retry on Fail” là giải pháp.

Hỏi: Tôi dùng n8n miễn phí, có bị giới hạn không?
Đáp: Có. Phiên bản miễn phí giới hạn 5000 execution/tháng và không có Queue Mode. Nếu workflow phức tạp, nâng lên bản Pro (khoảng 20$/tháng) là đủ cho SME.

Hỏi: Làm sao để biết workflow nào đang “đơ”?
Đáp: Vào Dashboard → Workflows → nhìn cột “Status”. Nếu có biểu tượng đồng hồ (Pending) hoặc dấu X (Error), click vào xem chi tiết. Hoặc dùng Error Workflow gửi thông báo real-time.

Hỏi: Tôi có thể dùng AI để sửa lỗi workflow không?
Đáp: Có. n8n 2026 tích hợp AI Agent. Bạn chỉ cần mô tả lỗi (ví dụ: “workflow chậm khi lấy dữ liệu từ Shopify”), AI sẽ tự đề xuất node và cấu hình. Nhưng vẫn cần kiểm tra tay.

Hành động ngay: 3 bước để workflow không bao giờ “đơ”

Đừng đọc xong rồi để đấy. Làm luôn nhé, 15 phút là xong.

Bước 1: Kiểm tra toàn bộ workflow hiện tại. Vào từng workflow, xem có lỗi Execution Timeout không. Set tối thiểu 60 giây. Thêm node “Respond to Webhook” nếu có Webhook.

Bước 2: Tạo Error Workflow. Chỉ mất 5 phút: tạo workflow mới, thêm node “Webhook” (nhận lỗi), node “Telegram” hoặc “Slack” để gửi thông báo. Trong workflow chính, vào Settings → Error Workflow → chọn workflow vừa tạo.

<