Lưu ý: Bài viết này có chứa affiliate link tới Make.com. Nếu bạn đăng ký qua link, Nhịp AI nhận một khoản hoa hồng nhỏ — không ảnh hưởng đến giá bạn trả.
TP.HCM, 03/09/2026. Một kịch bản tự động chạy êm suốt ba tuần, rồi sáng thứ Hai chủ shop mở máy thấy 47 đơn hàng không được ghi vào Google Sheets. Nguyên nhân hoá ra rất nhỏ: một khách điền số điện thoại có dấu cách, module gặp lỗi định dạng, và toàn bộ luồng dừng lại từ 2 giờ sáng mà không ai biết. Đây chính là lúc Make.com xử lý lỗi — cách gọi tắt cho toàn bộ lớp error handler mà nền tảng này cho phép gắn vào từng module — trở thành thứ quan trọng hơn cả việc dựng thêm kịch bản mới. Nếu bạn chưa có tài khoản, có thể dùng thử Make.com bản miễn phí để thực hành theo bài này; toàn bộ cơ chế được mô tả chi tiết trong tài liệu error handlers chính thức của Make.
Mục lục
- Make.com xử lý lỗi là gì và vì sao không thể bỏ qua
- Ba nhóm lỗi khiến kịch bản chết giữa chừng
- Sáu error handler trong Make.com xử lý lỗi: chọn cái nào?
- Dựng lớp Make.com xử lý lỗi cho kịch bản bán hàng trong 20 phút
- Chi phí thật: xử lý lỗi tốn thêm bao nhiêu operation
- Nhược điểm thật của cơ chế xử lý lỗi trên Make
- Make.com xử lý lỗi so với n8n và Zapier
- Câu hỏi thường gặp
- Bắt đầu từ đâu
Make.com xử lý lỗi là gì và vì sao không thể bỏ qua
Trong Make, mỗi module đều có thể được gắn thêm một nhánh riêng gọi là error handler. Nhánh này chỉ chạy khi module chính gặp lỗi, và nó quyết định chuyện gì xảy ra tiếp theo: dừng hẳn, bỏ qua bản ghi hỏng, thử lại sau, hay thay bằng một giá trị dự phòng. Toàn bộ tập hành vi đó là thứ chúng tôi gọi là Make.com xử lý lỗi trong bài này.
Mặc định, khi không gắn gì cả, Make dừng kịch bản ngay tại module lỗi và đánh dấu lần chạy đó là Error. Với một kịch bản chạy mỗi 15 phút, điều này nghe không nghiêm trọng — lần chạy sau sẽ tiếp tục. Nhưng với kịch bản xử lý theo lô hàng trăm bản ghi, một bản ghi hỏng ở vị trí thứ 12 sẽ khiến 88 bản ghi còn lại không bao giờ được chạm tới. Đó là khác biệt giữa một hệ thống tự động và một hệ thống chỉ có vẻ tự động.
Nếu bạn mới bắt đầu và chưa dựng kịch bản nào, hãy đọc hướng dẫn Make.com từ đầu trước, rồi quay lại bài này. Lớp Make.com xử lý lỗi chỉ có nghĩa khi bạn đã có ít nhất một luồng đang chạy thật.
Ba nhóm lỗi khiến kịch bản chết giữa chừng
Theo tài liệu của Make, lỗi trong một scenario được phân thành nhiều loại có tên riêng. Với người dùng Việt không phải dân kỹ thuật, có thể gom lại thành ba nhóm dễ nhớ.
Nhóm 1 — lỗi dữ liệu (DataError, IncompleteDataError). Khách điền sai định dạng, trường bắt buộc bị bỏ trống, ngày tháng gõ theo kiểu Việt Nam trong khi module chờ chuẩn ISO. Đây là nhóm chiếm phần lớn sự cố ở các kịch bản bán hàng và thu form. Điểm quan trọng: lỗi loại này chỉ hỏng ở một bản ghi, không phải hỏng cả hệ thống — nên cách Make.com xử lý lỗi đúng gần như luôn là bỏ qua bản ghi đó và đi tiếp.
Nhóm 2 — lỗi kết nối và giới hạn (ConnectionError, RateLimitError). API bên kia sập tạm thời, token OAuth hết hạn, hoặc bạn gọi quá số request cho phép trong một phút. Đặc điểm của nhóm này là tự khỏi: chờ vài phút rồi thử lại thường là chạy được. Với nhóm này, dừng hẳn kịch bản là phản ứng sai; thử lại mới đúng.
Nhóm 3 — lỗi cấu hình (InvalidConfigurationError, InvalidAccessTokenError). Bạn đổi mật khẩu tài khoản Google, hoặc xoá một cột trong Sheets mà kịch bản đang trỏ tới. Nhóm này không tự khỏi và cũng không nên bỏ qua — nó cần con người vào sửa. Cách xử lý đúng là dừng và báo động, chứ không phải âm thầm nuốt lỗi.
Phân biệt được ba nhóm này là nửa công việc của Make.com xử lý lỗi. Nửa còn lại là chọn đúng công cụ cho từng nhóm.
Sáu error handler trong Make.com xử lý lỗi: chọn cái nào?
Bộ công cụ Make.com xử lý lỗi gồm sáu directive đặt ở cuối nhánh error handler. Mỗi directive là một câu trả lời khác nhau cho câu hỏi “gặp lỗi rồi thì sao”.
| Directive | Hành vi | Trạng thái lần chạy | Dùng khi |
|---|---|---|---|
| Ignore | Bỏ qua bundle lỗi, các bundle sau vẫn chạy tiếp | Success | Lỗi dữ liệu lẻ tẻ trong lô lớn |
| Resume | Thay đầu ra của module lỗi bằng giá trị dự phòng bạn định sẵn rồi đi tiếp | Success | Thiếu một trường không quan trọng, có giá trị mặc định thay thế |
| Break | Tách bundle lỗi ra khỏi luồng, lưu thành incomplete execution kèm cấu hình thử lại | Warning | Lỗi kết nối, rate limit — thứ tự khỏi sau vài phút |
| Rollback | Dừng ngay và đưa các module trước đó về trạng thái trước khi chạy | Error | Giao dịch nhiều bước không được phép làm dở dang |
| Commit | Dừng hẳn nhưng giữ lại dữ liệu đã gửi đi thành công | Success | Muốn cắt sớm mà không huỷ phần đã làm được |
| Retry | Đưa bundle lỗi vào hàng đợi incomplete execution, phần còn lại của kịch bản vẫn chạy | Warning | Muốn tự tay xem lại từng bản ghi hỏng |
Quy tắc thực dụng: Ignore cho nhóm 1, Break cho nhóm 2, Rollback cho nhóm 3. Ba lựa chọn Make.com xử lý lỗi này phủ khoảng 90% tình huống mà một shop hoặc một team marketing gặp phải. Resume và Commit là công cụ tinh chỉnh, để dành cho khi bạn đã quen.
Một điểm dễ bỏ sót: muốn Break và Retry hoạt động, bạn phải bật tuỳ chọn lưu incomplete executions trong phần cài đặt của scenario. Nếu chưa bật, bundle lỗi biến mất và bạn mất luôn cơ hội chạy lại nó.
Dựng lớp Make.com xử lý lỗi cho kịch bản bán hàng trong 20 phút
Lấy đúng ví dụ đầu bài: form đơn hàng → chuẩn hoá dữ liệu → ghi vào Google Sheets → gửi tin nhắn xác nhận. Đây là bốn bước thêm lớp Make.com xử lý lỗi vào, làm theo thứ tự.
Bước 1 — bật lưu incomplete executions. Mở scenario, vào phần cài đặt ở góc dưới, tick tuỳ chọn cho phép lưu lần chạy dở dang. Đây là điều kiện tiên quyết của Make.com xử lý lỗi; bỏ qua bước này thì mọi thứ phía sau chỉ có tác dụng một nửa.
Bước 2 — gắn Ignore vào module ghi Sheets. Chuột phải vào module, chọn thêm error handler, kéo một directive Ignore vào cuối nhánh. Từ giờ, một số điện thoại có dấu cách không còn khả năng chặn 88 đơn hàng phía sau.
Bước 3 — gắn Break vào module gửi tin nhắn. Đây là module gọi API bên thứ ba, tức nhóm 2. Đặt số lần thử lại và khoảng cách giữa các lần — ba lần cách nhau 15 phút là cấu hình an toàn cho hầu hết dịch vụ nhắn tin ở Việt Nam. Nếu sau ba lần vẫn hỏng, bundle nằm lại trong hàng đợi để bạn xử lý tay.
Bước 4 — thêm nhánh báo động. Trước directive, chèn một module gửi email hoặc tin nhắn Telegram cho chính bạn, kèm nội dung lỗi. Đây là phần biến Make.com xử lý lỗi từ cơ chế phòng thủ thụ động thành hệ thống có người giám sát. Không có bước này, kịch bản vẫn im lặng — chỉ khác là im lặng một cách gọn gàng hơn.
Bốn bước này áp dụng được cho cả các kịch bản bán hàng mô tả trong bài 10 kịch bản Make.com cho shop online và cho luồng phân phối nội dung trong bài Make.com marketing tự động đăng bài.
Chi phí thật: xử lý lỗi tốn thêm bao nhiêu operation
Chi phí của Make.com xử lý lỗi là câu hỏi mà hầu hết bài hướng dẫn tiếng Anh bỏ qua, nhưng với người Việt trả tiền theo tỷ giá thì nó quan trọng.
Mỗi module trong nhánh Make.com xử lý lỗi khi được kích hoạt đều tính là một operation, giống module thường. Nghĩa là nhánh báo động ở Bước 4 chỉ tốn tiền khi thật sự có lỗi. Nếu kịch bản của bạn chạy sạch, lớp Make.com xử lý lỗi gần như miễn phí.
Phần tốn kém nằm ở Break với retry: mỗi lần thử lại là một lần chạy lại module đó. Cấu hình ba lần thử nghĩa là trong trường hợp xấu nhất, một bundle lỗi tiêu tốn gấp bốn lần operation so với bình thường. Với kịch bản chạy 30 bản ghi/ngày thì không đáng kể; với kịch bản 3.000 bản ghi/ngày và tỷ lệ lỗi 5%, con số này đủ để đẩy bạn từ gói Free lên gói Core trả phí của Make sớm hơn dự tính.
Lời khuyên: bắt đầu với hai lần thử lại thay vì ba, và đo thực tế trong hai tuần trước khi tăng. Bảng lịch sử lần chạy của Make cho biết chính xác bao nhiêu operation đã bị đốt cho việc thử lại.
Nhược điểm thật của cơ chế xử lý lỗi trên Make
Bài này không có ý bán cho bạn một giải pháp hoàn hảo. Make.com xử lý lỗi có bốn giới hạn thật cần biết trước.
Một, Make.com xử lý lỗi không hoạt động ở cấp toàn kịch bản. Bạn phải gắn error handler vào từng module một. Một scenario 15 module muốn phòng thủ đầy đủ thì phải cấu hình 15 lần, và mỗi lần sửa kịch bản lại phải nhớ gắn lại cho module mới. Đây là điểm mà n8n với khái niệm error workflow riêng làm gọn hơn.
Hai, Ignore che giấu vấn đề rất giỏi. Kịch bản báo Success, dashboard xanh mướt, trong khi mỗi ngày âm thầm mất 3 đơn hàng. Nếu dùng Ignore mà không kèm nhánh ghi log, bạn đang đánh đổi khả năng phát hiện lỗi lấy sự yên tâm giả.
Ba, Rollback không phải phép màu. Nó chỉ hoàn tác được những module có hỗ trợ giao dịch. Một email đã gửi đi thì không rút lại được, một tin nhắn Zalo đã tới tay khách cũng vậy. Đọc kỹ module nào thật sự hỗ trợ rollback trước khi tin vào nó.
Bốn, hàng đợi incomplete executions cần người dọn. Nó không tự xử lý. Nếu không ai mở ra xem hàng tuần, nó chỉ là nơi các bản ghi hỏng đi vào để bị quên lãng — tệ hơn cả việc kịch bản dừng hẳn, vì ít nhất kịch bản dừng thì bạn biết ngay.
Make.com xử lý lỗi so với n8n và Zapier
| Tiêu chí | Make | n8n | Zapier |
|---|---|---|---|
| Số directive | 6, gắn theo từng module | Error workflow riêng cho cả luồng | Autoreplay, cấu hình tối giản |
| Độ chi tiết | Cao — kiểm soát từng module | Cao, nhưng cần biết code JS | Thấp |
| Công sức cấu hình | Lặp lại theo từng module | Một lần cho cả workflow | Gần như không |
| Phù hợp với | Non-dev muốn kiểm soát chi tiết | Team có người biết kỹ thuật | Người muốn đơn giản tuyệt đối |
Kết luận ngắn: nếu bạn không viết code và vẫn muốn quyết định từng module hỏng thì làm gì, Make.com xử lý lỗi là lựa chọn cân bằng nhất hiện nay. Nếu đội bạn có người biết JavaScript và ngại chi phí thuê bao, n8n đáng cân nhắc — bài so sánh Activepieces, Make và n8n đi sâu vào chuyện này.
Câu hỏi thường gặp
Gắn Make.com xử lý lỗi có làm kịch bản chạy chậm đi không? Không. Nhánh error handler chỉ được kích hoạt khi module chính lỗi; lúc chạy bình thường nó nằm im và không tiêu tốn thời gian hay operation nào.
Tôi nên dùng Ignore hay Break cho lỗi Google Sheets? Tuỳ nguyên nhân. Sheets báo lỗi định dạng dữ liệu thì dùng Ignore. Sheets báo lỗi quota hoặc mất kết nối thì dùng Break kèm retry. Nếu chưa chắc, đọc tên lỗi hiển thị trong lịch sử lần chạy — Make ghi rõ loại lỗi ở đó.
Incomplete executions lưu được bao lâu? Chúng nằm trong hàng đợi cho tới khi bạn tự giải quyết hoặc xoá, nhưng dung lượng lưu trữ phụ thuộc gói dịch vụ. Đừng coi đây là nơi lưu trữ lâu dài — hãy đặt lịch dọn hàng tuần.
Có cần gắn Make.com xử lý lỗi cho mọi module không? Không cần. Ưu tiên ba vị trí: module ghi dữ liệu quan trọng, module gọi API bên thứ ba, và module cuối cùng của luồng. Ba chỗ này gây ra phần lớn sự cố thật.
Bắt đầu từ đâu
Đừng dựng lại kịch bản từ đầu. Mở scenario đang chạy nhiều nhất của bạn, bật lưu incomplete executions, rồi gắn đúng một directive Ignore vào module ghi dữ liệu. Mười phút, một thay đổi. Tuần sau quay lại xem lịch sử lần chạy để biết mình vừa cứu được bao nhiêu bản ghi.
Khi đã thấy hiệu quả, mở rộng lớp Make.com xử lý lỗi dần theo bốn bước ở trên. Nếu bạn chưa có tài khoản để thực hành, hãy mở tài khoản Make và dựng lớp xử lý lỗi đầu tiên — gói miễn phí đủ để làm hết bài này. Muốn hiểu thêm cách ghép AI vào giữa luồng sau khi đã phòng thủ xong, xem bài dùng Make và AI tự động hoá công việc.
Một hệ thống tự động tốt không phải là hệ thống không bao giờ lỗi. Nó là hệ thống biết mình vừa lỗi và báo cho bạn biết.
Đọc thêm: Cách lập content calendar 30 ngày bằng AI — trong 1 giờ · Cắt video bằng AI thành clip ngắn hút view · Workflow AI 2026: cẩm nang cho người mới
