Timeout là khi một yêu cầu hoặc một lần chạy vượt quá thời gian chờ cho phép và bị hủy. Trong n8n có ba loại hay gặp: node HTTP Request chờ API quá lâu (tùy chọn Timeout tính bằng mili giây), cả workflow vượt EXECUTIONS_TIMEOUT, và ứng dụng gọi webhook bỏ cuộc vì n8n phản hồi chậm.
Bài này giúp bạn nhận ra timeout trong n8n, phân biệt từng loại và xử lý đúng chỗ. Timeout thường đi cùng các lỗi API khác, xem bảng tổng hợp ở lỗi kết nối API thường gặp trong n8n. Nội dung đối chiếu docs.n8n.io ngày 22/10/2026.
Lỗi timeout trong n8n là gì?
Lỗi timeout xảy ra khi một tác vụ hoặc cả workflow chạy lâu hơn giới hạn thời gian đã đặt. Khi đó tiến trình bị ngắt, node báo lỗi và workflow dừng thay vì chạy tiếp.
Đây không phải lỗi của n8n mà là cơ chế bảo vệ: một lần gọi API, xử lý file lớn hay đoạn code nặng chạy quá lâu sẽ bị dừng để không giữ tài nguyên mãi và làm chậm các workflow khác. Gặp timeout là dấu hiệu workflow cần xem lại cách xử lý; nếu chỉ chậm mà chưa đứt, đọc thêm vì sao workflow n8n chạy chậm.
Dấu hiệu nhận biết khi gặp timeout
Trong danh sách và chi tiết lần chạy (Executions)
- Lần chạy báo Error: trong tab Executions, lần chạy đó có trạng thái lỗi màu đỏ.
- Node bị viền đỏ: mở chi tiết lần chạy, node gây lỗi có viền đỏ. Đây là “hiện trường” cần xem.
- Thông báo có chữ “timeout” hoặc mã liên quan: node HTTP Request thường báo mã
ECONNABORTEDkèm “timeout of …ms exceeded”; workflow vượt giới hạn chung bị hủy với trạng thái báo hết thời gian. Cách đọc chi tiết ở bài execution log.
Trong hành vi của workflow
- Chạy lâu bất thường: workflow vốn xong trong vài giây nay đứng nhiều phút ở một node.
- Dữ liệu chỉ xử lý một phần: cần xử lý 1.000 dòng nhưng chỉ 200–300 dòng thành công rồi workflow dừng.
- Bên gọi webhook báo lỗi dù n8n vẫn chạy: form, cổng thanh toán nhận lỗi hết thời gian chờ trong khi execution trên n8n vẫn tiếp tục.
Nguyên nhân gây lỗi timeout trong n8n
- Xử lý khối lượng dữ liệu lớn: hàng nghìn dòng Google Sheets, truy vấn database nặng trong một lần chạy.
- Giới hạn đã đặt: option Timeout của HTTP Request,
EXECUTIONS_TIMEOUThoặc timeout trong Workflow settings quá ngắn so với việc cần làm. - Thiếu tài nguyên: máy chủ thiếu CPU hoặc RAM, mọi node chậm lại rồi chạm giới hạn.
- API bên ngoài phản hồi chậm: CRM, dịch vụ email, OpenAI… trả lời lâu hơn bình thường.
- Mạng không ổn định: đường truyền chập chờn, request không về kịp.
- Logic nặng trong node Code: vòng lặp lồng nhau trên mảng lớn, xử lý văn bản nặng cho từng item.
- Thiết kế workflow chưa tối ưu: gọi API liên tục không nghỉ, lặp thừa.
Phân biệt timeout do bạn đặt và timeout do quá tải
Ví dụ: workflow lấy thời tiết từ API OpenWeatherMap bằng node HTTP Request, thêm option Timeout = 200 (mili giây, tức 0,2 giây). Thời gian này quá ngắn để request đi và về, nên n8n chủ động hủy kết nối và báo ECONNABORTED, “timeout of 200ms exceeded”.
Máy chủ API không hề sập; chính n8n “thiếu kiên nhẫn”. Vì vậy có hai dạng timeout:
Timeout do bạn cấu hình
Giới hạn chờ đặt ở node (HTTP Request Timeout) hoặc ở workflow quá ngắn so với thời gian dịch vụ cần. Giống như tự đặt quy tắc “sau 2 hồi chuông không ai nghe thì cúp máy”. Sửa bằng cách đặt giới hạn hợp lý.
Timeout do quá tải hoặc dữ liệu quá lớn
Workflow xử lý quá nhiều dữ liệu hoặc logic quá nặng nên tổng thời gian vượt giới hạn chung, hoặc máy chủ hết tài nguyên. Giống cuộc gọi kéo dài tới mức điện thoại hết pin. Sửa bằng cách chia nhỏ dữ liệu và tối ưu workflow.
Cách xử lý và phòng tránh lỗi timeout trong n8n
1. Thiết kế workflow để không phải chờ lâu
Chia lô bằng Loop Over Items. Khi danh sách có thể lớn hơn vài chục mục, đặt node Loop Over Items (tên mới của Split in Batches) ngay sau bước lấy dữ liệu. Thay vì xử lý 10.000 item cùng lúc, chia thành 100 lô, mỗi lô 100 item: mỗi bước ngắn, ít tốn bộ nhớ.
Tách thành sub-workflow. Đưa phần việc nặng sang workflow con và gọi bằng node Execute Sub-workflow, xem cách tạo sub-workflow trên n8n. Mỗi workflow con có lần chạy và lịch sử riêng, dễ tìm phần chậm và chạy lại riêng phần lỗi.
Webhook: trả lời trước, xử lý sau. Bên gọi webhook (form, cổng thanh toán) thường chỉ chờ vài chục giây. Trong node Webhook, đặt Respond = Immediately, hoặc đặt node Respond to Webhook ngay sau bước nhận và kiểm dữ liệu; các bước tốn thời gian để phía sau. Chi tiết ở bài node Webhook.
Trên n8n Cloud, webhook không phản hồi trong 100 giây sẽ trả lỗi 524 (Webhook common issues). Việc chạy rất lâu nên tách thành hai webhook: một webhook khởi động và trả lời ngay, một webhook để bên gọi hỏi trạng thái và lấy kết quả.
Queue mode không làm webhook trả lời nhanh hơn. Queue mode (EXECUTIONS_MODE=queue, cần Redis và worker) dùng để chia tải khi có nhiều lần chạy đồng thời trên bản tự host. Muốn bên gọi không chờ, vẫn phải cấu hình Respond như trên.
2. Tối ưu ở từng node
Đặt Timeout hợp lý cho HTTP Request. Trong node HTTP Request, Add option > Timeout (mili giây). Với API thông thường, 15.000–30.000 ms (15–30 giây) là hợp lý: API không trả lời thì báo lỗi để bạn xử lý, thay vì treo mãi.
Thử lại khi lỗi tạm thời. Trong Settings của node, bật Retry On Fail, đặt số lần thử và thời gian chờ giữa các lần.
Dùng node Wait với API giới hạn tốc độ. Chèn node Wait giữa các lô để không bị chặn vì gửi quá nhiều request.
Bắt lỗi chủ động bằng Error workflow. Tạo một workflow bắt đầu bằng node Error Trigger (ghi log, gửi cảnh báo Telegram, email), rồi chọn nó ở mục Error workflow trong Settings của workflow chính. Khi một node timeout, bạn nhận cảnh báo kèm tên node và thông báo lỗi.
Viết code hiệu quả trong node Code. Tránh vòng lặp lồng nhau trên mảng lớn; tách việc gọi API ra node HTTP Request thay vì gọi trong code.
3. Cấu hình môi trường (bản tự host)
Đủ tài nguyên. Theo dõi CPU, RAM khi workflow nặng chạy; thiếu thì nâng cấp máy chủ. Gợi ý cấu hình có ở cấu hình tối thiểu để triển khai n8n trên VPS.
Biến môi trường về timeout (docs: Executions environment variables):
Biến Mặc định Ý nghĩa EXECUTIONS_TIMEOUT-1 (không giới hạn)Thời gian chạy tối đa (giây) áp cho mọi workflow; quá giới hạn n8n dừng lần chạy EXECUTIONS_TIMEOUT_MAX3600Mức tối đa (giây) mà người dùng được đặt cho từng workflow trong Workflow settings EXECUTIONS_MODEregularqueue để chạy bằng Redis + worker khi cần chia tải
Ví dụ trong docker-compose.yml, giới hạn mặc định 30 phút cho mọi workflow và cho phép đặt riêng tối đa 2 giờ:
environment:
- EXECUTIONS_TIMEOUT=1800
- EXECUTIONS_TIMEOUT_MAX=7200Theo docs: Configure workflow timeout, workflow chạy trong tiến trình chính sẽ dừng “mềm” sau khi node hiện tại chạy xong; workflow chạy ở tiến trình riêng bị dừng mềm trước, rồi bị buộc dừng nếu sau thêm một phần năm thời gian vẫn chưa dừng. Ở n8n Cloud, bản dùng thử giới hạn mỗi lần chạy 180 giây (trang giá n8n, 22/10/2026).
Mạng ổn định. Kiểm tra kết nối từ máy chủ n8n tới API (độ trễ, DNS, tường lửa chặn cổng ra).
Muốn chạy n8n 24/7 mà không tự cài? VPS n8n của Tino cài sẵn n8n trên VPS NVMe đặt tại Việt Nam; bạn vẫn có quyền root để cấu hình. Xem cấu hình và giá trên trang sản phẩm.
Kết luận
Timeout trong n8n có ba điểm: node HTTP Request, cả workflow và webhook phía bên gọi. Xác định đúng điểm, rồi chọn cách sửa tương ứng: đặt Timeout hợp lý, chia lô và tách workflow con, trả lời webhook sớm, và chỉ nới giới hạn khi việc đó thật sự cần thời gian.
Những câu hỏi thường gặp
Làm sao biết chính xác node nào gây timeout?
Mở lần chạy lỗi trong tab Executions; node viền đỏ là nơi lỗi. Bấm vào node để đọc thông báo, ví dụ ECONNABORTED ở HTTP Request. Rê chuột lên các node khác để xem thời gian chạy của từng node.
Tăng giới hạn timeout thật cao có phải giải pháp tốt?
Chỉ nên tạm thời. Nới giới hạn che đi việc workflow đang chậm; tối ưu (chia lô, tách sub-workflow, giảm dữ liệu) mới xử lý gốc. Với webhook, nới giới hạn phía n8n không giúp được bên gọi vốn chỉ chờ một khoảng cố định.
Lỗi 408 Request Timeout khác timeout của n8n thế nào?
Timeout của n8n là n8n tự dừng request hoặc lần chạy vì quá giới hạn đã đặt. 408 Request Timeout là máy chủ API trả về, báo nó không nhận được request đầy đủ trong thời gian nó chờ. 504, 524 là cổng hoặc proxy (ví dụ Cloudflare) chờ máy chủ phía sau quá lâu.
Cách xử lý hàng nghìn item mà không bị timeout?
Dùng Loop Over Items chia lô (ví dụ 100 item mỗi lô), thêm Wait giữa các lô nếu API giới hạn tốc độ, và đưa phần xử lý mỗi lô vào sub-workflow nếu nặng.
Sub-workflow giúp tránh timeout như thế nào?
Workflow con có lần chạy riêng, nên bạn thấy rõ phần nào chậm và chạy lại riêng phần lỗi. Lưu ý giới hạn EXECUTIONS_TIMEOUT áp cho từng workflow; workflow cha chờ con (mặc định) thì tổng thời gian của cha vẫn tính cả thời gian chờ.
