Tự động hoá quy trình làm việc trong n8n để kiểm tra website theo lịch và gửi email cảnh báo khi lỗi

Website của bạn có thể vẫn mở được với khách nhưng trả về mã lỗi, chuyển hướng sai hoặc phản hồi quá khác với lúc bình thường. Bài này dùng tự động hoá quy trình làm việc trong n8n để kiểm tra một URL theo lịch, rẽ nhánh theo mã HTTP và gửi email khi điều kiện lỗi xảy ra; phần cuối cũng chỉ rõ cách chạy thử và bật lịch nền.

Quy trình làm việc là gì trong ca trực website: mẫu quy trình làm việc bốn node

Nếu bạn đang hỏi “quy trình làm việc là gì” trong trường hợp này, hãy thu nhỏ việc cần làm thành một luồng rất cụ thể: lấy một URL, gọi URL đó theo lịch, đọc mã phản hồi, rồi quyết định có gửi thư hay không. Không kiểm tra nhiều website, không thêm bước phân tích nội dung và không gửi thông báo cho mọi lần chạy. Mục tiêu của lượt kiểm tra đầu tiên chỉ là phát hiện URL không trả về mã mà bạn đã chọn.

Mẫu quy trình làm việc gồm bốn chặng: Schedule Trigger khởi động theo lịch, HTTP Request gọi website, IF so sánh mã phản hồi và Send Email gửi cảnh báo nếu điều kiện đúng. Nhánh còn lại không cần gửi gì; bạn có thể để nhánh đó không nối tiếp hoặc nối vào một node không thực hiện hành động nếu phiên bản n8n của bạn có cách đặt tên tương ứng. Khi làm xong, hãy tự hỏi một câu: “Nếu URL trả về mã bình thường, luồng có dừng mà không gửi thư không?” Nếu câu trả lời là có, phạm vi ban đầu đã đủ rõ.

Cách xây dựng quy trình làm việc: cách tạo workflows trong n8n theo lịch

Trước khi mở n8n, ghi ra ba giá trị: URL cần theo dõi, mã được xem là bình thường và khoảng thời gian muốn kiểm tra. Trong bài thử này, dùng mã 200 làm điều kiện không cảnh báo và dùng một URL thử có thể trả về mã 500 để kiểm tra nhánh lỗi. Đừng lấy ngay trang thanh toán hoặc trang quản trị làm URL thử; một lượt kiểm tra sai có thể tạo thư cảnh báo thật hoặc gây tải không cần thiết.

Trong n8n, tạo workflow mới rồi thêm các node theo thứ tự dưới đây. Tên trường có thể khác đôi chút giữa các bản n8n, nên nếu giao diện không giống, tìm theo tên node và mô tả chức năng thay vì cố tìm đúng vị trí nút.

1. 1Thêm node Schedule Trigger.
2. 2Chọn lịch chạy đủ thưa để thử nghiệm, chẳng hạn một lịch mà bạn có thể dễ dàng đối chiếu với thời gian hiện tại.
3. 3Thêm node HTTP Request và nối từ Schedule Trigger sang node này.
4. 4Chọn phương thức GET.
5. 5Nhập URL cần theo dõi.
6. 6Thêm node IF và nối từ HTTP Request sang node này.
7. 7Thêm node Send Email ở nhánh điều kiện đúng của IF.
8. 8Để nhánh điều kiện sai không nối tiếp nếu mục tiêu là không làm gì khi website bình thường.

Dấu hiệu xong của phần này là trên canvas có đường đi từ Schedule Trigger đến HTTP Request, từ HTTP Request đến IF, và từ một nhánh của IF đến Send Email. Nếu n8n báo node chưa được nối hoặc không cho chạy, kiểm tra lại node đang được chọn khi kéo đường nối. Chưa cần bật workflow ở bước này; chạy tay trước để tránh lịch nền gửi thư khi cấu hình còn dở.

Cấu hình lịch và URL để có thể tái tạo lượt thử

Trong Schedule Trigger, đặt lịch mà bạn có thể nhớ và kiểm tra lại, không nên chọn một thời điểm quá xa chỉ để mô phỏng vận hành. Lịch này chỉ có tác dụng khởi động workflow; nó không quyết định website trả về mã nào. Trong HTTP Request, nhập đúng URL đầy đủ, bao gồm giao thức nếu trường yêu cầu. Nếu URL cần đăng nhập, bài kiểm tra cơ bản này chưa chứng minh được phần nội dung sau đăng nhập có hoạt động.

Bấm chạy thủ công workflow để dựng lần chạy đầu tiên. Dấu hiệu đã qua bước là execution xuất hiện và node HTTP Request nhận được dữ liệu thay vì lỗi cấu hình URL. Nếu node Schedule Trigger không chạy như bạn mong đợi khi chạy tay, đó là khác biệt giữa việc gọi thử và việc chờ lịch; dùng nút chạy thử của workflow hoặc node đang được hỗ trợ trong giao diện bản bạn dùng, rồi kiểm tra execution tương ứng.

n8n tự động hóa quy trình làm việc: để HTTP 500 đi tiếp tới nhánh cảnh báo

Nếu HTTP Request coi mọi mã ngoài điều kiện thành lỗi hệ thống, workflow có thể dừng ngay tại node kiểm tra. Khi đó IF không nhận được dữ liệu để quyết định, dù chính mã lỗi lại là thứ bạn cần dùng để gửi cảnh báo. Trong mục tuỳ chọn của HTTP Request, tìm thiết lập có ý nghĩa tương đương không dừng workflow khi HTTP trả về lỗi; ở nhiều bản n8n, thiết lập này được gọi là Never Error. Tên và vị trí có thể thay đổi theo phiên bản, nên hãy đọc phần mô tả ngay cạnh trường đó.

Bản dùng để dựng và chạy bài này là n8n 2.35.7; tên hai tuỳ chọn dưới đây trong tệp workflow là neverError và fullResponse, nằm trong phần options của node. Tên hiển thị trên giao diện đổi theo bản, nhưng hai khoá đó thì không. Bạn cũng cần yêu cầu HTTP Request trả về mã trạng thái cùng phản hồi. Trong giao diện, tìm tuỳ chọn có ý nghĩa tương đương bao gồm tiêu đề và mã trạng thái trong phản hồi; một số bản hiển thị là Include Response Headers and Status. Khi bật, dữ liệu đầu ra thường có trường mã trạng thái như statusCode, nhưng cấu trúc chính xác có thể khác nếu bạn chọn định dạng phản hồi khác. Hãy mở dữ liệu đầu ra của node sau một lượt chạy để xem tên trường thực tế, không đoán từ ví dụ trên mạng.

1. 1Bật tuỳ chọn để HTTP Request không dừng workflow vì mã HTTP lỗi.
2. 2Bật tuỳ chọn đưa mã trạng thái vào dữ liệu đầu ra.
3. 3Chạy riêng node HTTP Request với một URL thử.
4. 4Mở dữ liệu đầu ra và tìm trường chứa mã trạng thái.
5. 5Trong IF, chọn trường đó làm giá trị bên trái.
6. 6Chọn phép so sánh khác — không phải "bằng". Đây là chỗ dễ làm ngược nhất cả bài.
7. 7Nhập 200 làm giá trị bên phải, và chọn kiểu số chứ không phải chuỗi.

Điều kiện đọc thành câu là "mã trả về khác 200". Nhánh true vì thế là nhánh trang đang hỏng, và đó là nhánh nối vào node gửi thư. Đặt "bằng 200" rồi vẫn nối thư vào nhánh true là dựng ra một cái báo động kêu đúng lúc mọi thứ bình thường và im lặng đúng lúc sập — tệ hơn không có báo động, vì bạn sẽ tin nó.

Dấu hiệu đã xong là lượt trả về 500 vẫn tạo dữ liệu đầu ra và có mã trạng thái để IF đọc. Nếu node vẫn chuyển sang trạng thái lỗi màu đỏ, đường lùi là mở lại phần tuỳ chọn HTTP Request, kiểm tra thiết lập không dừng vì lỗi và chạy lại; nếu không thấy tuỳ chọn đó, tra tài liệu của đúng phiên bản n8n đang dùng thay vì bật đại một thiết lập có tên gần giống. Đây là phần cốt lõi của tự động hoá quy trình làm việc: lỗi HTTP phải trở thành dữ liệu để xử lý, không phải lý do làm luồng biến mất giữa chừng.

Tự động gửi email thông báo: kiểm thử đủ nhánh 200 và 500

Mở node Send Email và điền thông tin kết nối máy chủ thư theo tài khoản bạn được phép sử dụng. Nhập rõ người gửi, người nhận, tiêu đề và nội dung. Nội dung nên chứa URL, mã trạng thái nhận được và thời điểm chạy; nếu lấy giá trị từ dữ liệu đầu ra, chọn trường bằng trình chọn của n8n để giảm nguy cơ gõ sai đường dẫn. Không dán mật khẩu hoặc khoá truy cập trực tiếp vào nội dung node nếu n8n của bạn có khu vực thông tin xác thực riêng.

Một email cảnh báo tối thiểu phải trả lời được bốn câu: URL nào bị kiểm tra, nhận mã gì, lúc nào nhận mã đó và người nhận cần kiểm tra ở đâu. Trường người gửi và người nhận không được để trống. Tiêu đề cũng không nên để nguyên giá trị mẫu của node, vì sau này bạn có thể không phân biệt được thư kiểm tra với thư cảnh báo thật. Nếu n8n báo lỗi kết nối máy chủ thư, dừng ở đây và kiểm tra thông tin xác thực, cổng, mã hoá và quyền gửi của tài khoản; đừng kết luận rằng IF đang đi sai nhánh khi email chưa thể kết nối.

Thực hiện hai lượt thử bắt buộc, mỗi lượt kiểm tra cả execution lẫn hộp thư:

1. 1Dùng URL trả về 200 rồi chạy workflow thủ công.
2. 2Mở dữ liệu của IF và xác nhận điều kiện là sai.
3. 3Kiểm tra hộp thư và xác nhận không có email cảnh báo từ lượt này.
4. 4Dùng URL hoặc điểm thử trả về 500 rồi chạy workflow thủ công lần nữa.
5. 5Mở dữ liệu của IF và xác nhận điều kiện là đúng.
6. 6Kiểm tra email có người gửi, người nhận, tiêu đề và thân thư không rỗng.

Lượt thử thứ hai vướng một câu hỏi thật: lấy đâu ra một địa chỉ trả 500 mà không phải làm hỏng trang đang chạy? Có hai đường, và đường thứ nhất không đụng vào gì cả.

Cách không rủi ro — đổi ngưỡng so sánh, không đụng website. Vào node IF, tạm đổi giá trị bên phải từ 200 sang một số không bao giờ xảy ra, ví dụ 999. Trang vẫn khoẻ và vẫn trả 200, nhưng 200 thì khác 999, nên điều kiện thành đúng và luồng rẽ sang nhánh cảnh báo. Bạn kiểm được trọn nhánh gửi thư — kể cả nội dung thư — mà không ai phải chịu một phút chết trang. Thử xong nhớ đổi lại 200.

Cách gần thật hơn — làm hỏng một bản chép của site. Trên một bản chạy trên máy hoặc bản dựng thử, bật một plugin gọi hàm không tồn tại; PHP ném lỗi nghiêm trọng và máy chủ trả 500 thật. Đây là cách tôi dùng khi dựng bài này: trang chủ chuyển từ 200 sang 500, và thư cảnh báo tới ngay ở lượt chạy kế tiếp.

⚠ Đừng làm hỏng trang thật để thử báo động. Nếu chỉ có một môi trường duy nhất thì dùng cách thứ nhất.

Dấu hiệu hoàn tất là lượt 200 không gửi thư, còn lượt 500 đi vào Send Email và tạo được thư đầy đủ. Nếu lượt 500 không có mã trạng thái, quay lại HTTP Request; nếu có mã nhưng không vào Send Email, xem lại trường và phép so sánh trong IF; nếu vào Send Email nhưng thư rỗng, mở phần biểu thức trong tiêu đề và thân thư để đối chiếu với dữ liệu đầu ra thực tế. Hai lượt thử này chỉ xác nhận logic của workflow, chưa chứng minh mọi lỗi website đều được phát hiện.

Quản lý quy trình làm việc sau khi chạy tay: múi giờ và bật lịch

Đặt múi giờ ở cấp workflow thành Asia/Ho_Chi_Minh nếu workflow của bạn hỗ trợ thiết lập riêng cho múi giờ. Sau đó chạy thử một lượt và đối chiếu thời gian hiển thị trong execution với thời gian trong email. Nếu hai thời gian lệch nhau, kiểm tra cả múi giờ của workflow, máy chủ n8n và tài khoản gửi thư; bản thân việc đổi một trường không đảm bảo mọi nơi hiển thị cùng múi giờ.

Chạy tay chỉ để kiểm tra logic ngay lúc bạn bấm nút. Muốn n8n tự gọi theo lịch, bạn phải kích hoạt workflow sau khi đã kiểm tra hai nhánh. Dấu hiệu lịch nền đã sẵn sàng là workflow hiển thị trạng thái hoạt động theo cách bản n8n của bạn quy định; đừng dựa vào việc execution thủ công vừa chạy thành công. Nếu chưa muốn nhận thư thật, giữ workflow ở trạng thái chưa kích hoạt và dùng URL thử trong các lượt kiểm tra tiếp theo.

Các vấn đề thường gặp n8n trước khi đưa luồng vào chạy thật

Trước khi bật lâu dài, kiểm tra lần lượt: HTTP Request có dừng khi gặp lỗi hay vẫn trả dữ liệu; trường mã trạng thái có thực sự tồn tại; IF có so sánh đúng trường và đúng kiểu giá trị; nhánh 200 có không gửi thư; nhánh 500 có gửi thư với đủ người gửi, người nhận, tiêu đề và thân thư; múi giờ trong execution có khớp giờ bạn dự kiến. Luồng này chỉ theo dõi URL và điều kiện bạn đã cấu hình, không tự biết trang hiển thị đúng nội dung hay toàn bộ chức năng website còn hoạt động. Lịch quá dày có thể tạo nhiều yêu cầu và nhiều thư; lỗi kéo dài cũng có thể khiến một cảnh báo bị gửi lặp ở mỗi lượt chạy. Vì vậy, trước khi dùng thật, quyết định rõ tần suất chấp nhận được, ai nhận cảnh báo và có cần thêm bước chống gửi lặp hay không.