Phân tích Cron Expression

Công cụ phân tích và giải thích Cron Expression online miễn phí. Phân tích, kiểm tra và hiểu biểu thức lịch trình cron cho Linux, Unix và Quartz với mô tả dễ hiểu và thời gian chạy tiếp theo. Hoàn hảo cho lập trình viên và quản trị viên hệ thống.

Biểu thức Cron

Xóa

Dán

Múi giờ hiển thị

Thời gian chạy tiếp theo hiển thị theo múi giờ này

Ví dụ phổ biến

Có góp ý? Báo lỗi, đề xuất tính năng, hoặc chia sẻ suy nghĩ — chúng tôi đọc tất cả

Phân tích Cron Expression - Parse và Giải thích lịch trình Cron

Công cụ phân tích Cron Expression online mạnh mẽ giúp bạn hiểu, kiểm tra và giải thích biểu thức lịch trình cron. Hỗ trợ cả định dạng Unix/Linux (5 trường) và Quartz (6-7 trường) với phân tích chi tiết từng trường và xem trước thời gian chạy tiếp theo. Hoàn hảo để hiểu các cron job hiện có và kiểm tra cú pháp cron.

Biểu thức cron là gì và đọc thế nào?

Biểu thức cron là chuỗi 5 hoặc 6 trường định nghĩa khi nào một công việc lặp lại nên chạy. Cron Unix chuẩn có 5 trường: phút (0-59), giờ (0-23), ngày trong tháng (1-31), tháng (1-12), thứ trong tuần (0-6, Chủ Nhật là 0 hoặc 7). Nhiều bộ lập lịch mới hơn (Quartz, Spring, Jenkins, AWS EventBridge) thêm trường thứ 6 là giây ở đầu và trường thứ 7 là năm ở cuối. Chuỗi "0 9 * * 1-5" nghĩa là "lúc 09:00 từ Thứ Hai đến Thứ Sáu." Ký tự * nghĩa là "mọi giá trị," / nghĩa là "bước" (*/15 = mỗi 15), - là khoảng (1-5), và , là danh sách (1,3,5). Trang man Vixie cron là tham chiếu chuẩn cho định dạng 5 trường gốc, RFC 4954 đề cập một số ngữ nghĩa lập lịch, và tài liệu Quartz đề cập phương ngữ mở rộng.

Làm sao tìm thời gian chạy tiếp theo của biểu thức cron?

Dán biểu thức vào parser và xem thẻ "Thời gian chạy tiếp theo" — nó liệt kê 5-10 lần chạy kế tiếp cùng đồng hồ đếm ngược trực tiếp tới lần gần nhất. Quan trọng: hãy chọn đúng múi giờ trong danh sách thả xuống trước, vì công cụ này tính các thời điểm đồng hồ khớp theo múi giờ bạn chọn (UTC, Asia/Tokyo, v.v.), chứ không chỉ định dạng lại một thời điểm duy nhất, nên các lần chạy hiển thị vẫn đúng kể cả khi trình duyệt của bạn ở múi giờ khác. Để kiểm tra lịch trước khi triển khai, đổi múi giờ sang múi mà máy chủ hoặc cụm của bạn dùng rồi xác nhận các lần chạy tiếp theo rơi đúng chỗ bạn mong đợi. Các macro như @daily mở rộng thành 0 0 * * * và xem trước bình thường; @reboot không có giờ đồng hồ (chạy một lần khi daemon khởi động) nên hiển thị ghi chú khởi động thay vì danh sách.

Khác biệt giữa */5 và 0/5 trong trường phút là gì?

Cả hai đều có nghĩa "mỗi 5 phút bắt đầu từ 0," nhưng đi tới đó theo đường cú pháp khác nhau. */5 nghĩa là "bước 5 trên toàn dải," tạo ra 0, 5, 10, 15, ..., 55. 0/5 là cú pháp mở rộng Quartz/Spring nghĩa là "bắt đầu ở 0, bước 5," giống hệt về kết quả. Tuy nhiên, 3/5 nghĩa rõ ràng là "bắt đầu ở 3 rồi bước 5": 3, 8, 13, 18, ..., 58. Vixie cron chuẩn không hỗ trợ cú pháp N/M (chỉ */M); nếu bạn viết 3/5 trong crontab Linux nguyên bản, nó sẽ thất bại âm thầm hoặc bị hiểu sai. Luôn kiểm tra runtime đích dùng Vixie cron, croniter (Python), node-cron, Quartz hay Spring — chúng khác nhau đúng ở góc này. AWS EventBridge đặc biệt dùng định dạng 6 trường kiểu Quartz và ngữ nghĩa thứ trong tuần kỳ quặc.

Vì sao ngày trong tháng và thứ trong tuần được hiểu là OR, không phải AND?

Đây là quy tắc cron gây ngạc nhiên nhất. "0 0 13 * 5" KHÔNG có nghĩa "ngày 13 của tháng VÀ chỉ vào Thứ Sáu" — nó có nghĩa "ngày 13 của bất kỳ tháng nào, HOẶC bất kỳ Thứ Sáu nào." Khi cả ngày-trong-tháng và thứ-trong-tuần đều bị hạn chế (không phải *), Vixie cron cổ điển và hầu hết hậu duệ đối xử chúng như hợp, không phải giao. BSD cron gốc dùng giao, nhưng Vixie cron cố ý chuyển sang hợp năm 1992 để phù hợp kỳ vọng người dùng cho những thứ như "ngày làm việc cộng ngày 1" ("0 9 1 * 1-5" = 9 sáng các ngày làm việc HOẶC ngày 1 bất kỳ tháng). Để có giao thật (cảnh báo Thứ Sáu ngày 13), bạn thường cần một bảo vệ trong chính công việc, hoặc dùng ? đặc biệt của Quartz ở một trong các trường ngày để giải nhập nhằng. Đặc tả Quartz yêu cầu đúng một trong ngày-trong-tháng/thứ-trong-tuần là ? để rõ ràng.

@reboot, @daily, @weekly, @yearly và @hourly nghĩa là gì?

Các biệt danh này là lối tắt do Vixie cron định nghĩa cho các lịch phổ biến. @yearly (bí danh @annually) = 0 0 1 1 * (nửa đêm 1 tháng 1). @monthly = 0 0 1 * * (nửa đêm ngày 1). @weekly = 0 0 * * 0 (nửa đêm Chủ Nhật). @daily (bí danh @midnight) = 0 0 * * * (nửa đêm mỗi ngày). @hourly = 0 * * * * (đầu mỗi giờ). @reboot đặc biệt: chạy một lần khi cron daemon khởi động, thường khi khởi động hệ thống — hữu ích cho tác vụ khởi động dịch vụ nhưng không tin cậy trong môi trường container nơi cron daemon có thể khởi động lại vì lý do khác. Timer systemd và Kubernetes CronJob không hỗ trợ @reboot về mặt ngữ nghĩa. Một số phiên bản cũng hỗ trợ @minutely (mỗi phút) nhưng không chuẩn.

Phân tích Cron Expression — Công cụ phân tích và giải thích Cron Expression online miễn phí. Phân tích, kiểm tra và hiểu biểu thức lịch trình cron c — **Phân tích Cron Expression**

Làm sao chạy công việc mỗi 5 phút từ 9 sáng đến 5 chiều các ngày làm việc?

Biểu thức là "*/5 9-17 * * 1-5" nghĩa là mỗi 5 phút (phút 0, 5, 10, ..., 55) của các giờ 9 đến 17, bất kỳ ngày tháng nào, bất kỳ tháng nào, Thứ Hai đến Thứ Sáu. Hai điểm tinh tế: cái này cũng kích hoạt lúc 17:00, 17:05, ..., 17:55 — không chỉ 17:00. Để dừng đúng 17:00, dùng "*/5 9-16 * * 1-5" + "0 17 * * 1-5". Ngoài ra, thứ-trong-tuần 1-5 là Thứ Hai-Thứ Sáu trong Linux cron, nhưng trong Quartz và AWS EventBridge, Chủ Nhật là 1 và Thứ Bảy là 7, nên Thứ Hai-Thứ Sáu là 2-6 — lỗi lệch một thường gặp. Luôn kiểm tra trong bộ lập lịch đích. Các parser cron trực tuyến như trên trang này hiển thị 5-10 lần chạy tiếp theo để bạn kiểm tra biểu thức trực quan.

Khác biệt giữa cron, timer systemd và Kubernetes CronJob là gì?

Cả ba đều lập lịch công việc lặp nhưng với các đảm bảo khác nhau. Cron Unix cổ điển đơn giản, phổ biến, nhưng không có logging, không theo dõi phụ thuộc, không thử lại, và gửi lỗi âm thầm qua email tới root. Timer systemd là thay thế Linux hiện đại: tích hợp journal (log có cấu trúc), hỗ trợ OnBootSec / OnCalendar (phong phú hơn cú pháp cron), xử lý lần chạy bị lỡ (Persistent=true bắt kịp nếu hệ thống tắt), và có phụ thuộc unit. Kubernetes CronJob dùng biểu thức cron 5 trường kiểu Quartz nhưng thêm concurrencyPolicy (Allow/Forbid/Replace), startingDeadlineSeconds, và giới hạn lịch sử thành công/thất bại. Bộ lập lịch đám mây (AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps) thêm thử lại, hàng đợi thư chết, và khả năng quan sát. Cho mọi thứ ngoài máy chủ sở thích, ưu tiên timer systemd hoặc bộ lập lịch đám mây hơn cron thô.

Khác biệt giữa L, W và # trong biểu thức cron Quartz là gì?

Đây là phần mở rộng Quartz không có trong Vixie cron chuẩn. L nghĩa là "cuối cùng": L trong ngày-trong-tháng = ngày cuối của tháng (xử lý 28/29/30/31 tự động), 5L trong thứ-trong-tuần = Thứ Sáu cuối cùng của tháng. W nghĩa là "ngày làm việc gần nhất": 15W = ngày làm việc gần ngày 15 nhất (nếu 15 là Thứ Bảy, kích hoạt Thứ Sáu ngày 14; nếu Chủ Nhật, Thứ Hai ngày 16). LW kết hợp = ngày làm việc cuối cùng của tháng — hữu ích cho lương. # chỉ định lần thứ N: 2#3 trong thứ-trong-tuần = Thứ Ba thứ ba của tháng (vì Quartz dùng 1=CN, 2=T2, ..., 7=T7). Các mở rộng này xử lý quy tắc nghiệp vụ thực tế ("Thứ Hai thứ hai mỗi tháng", "ngày làm việc cuối cho hóa đơn") mà cron 5 trường thuần không thể biểu đạt. AWS EventBridge hỗ trợ L và # nhưng không hỗ trợ W.

Múi giờ ảnh hưởng đến lịch cron thế nào?

Vixie cron cổ điển chạy theo múi giờ địa phương của hệ thống (biến TZ), gây ra các lỗi đau đầu quanh chuyển đổi giờ tiết kiệm ánh sáng. Ở múi giờ có chỉnh tiến mùa xuân, công việc lên lịch lúc 02:30 đơn giản không chạy ngày đó. Với lùi lại mùa thu, công việc lúc 01:30 chạy hai lần. Timer systemd mặc định UTC trừ khi OnCalendar chỉ định TZ. Quartz và Kubernetes CronJob đều hỗ trợ trường múi giờ tường minh (spec.timeZone trong CronJob 1.27+) để cùng biểu thức hoạt động giống nhau qua các khu vực. AWS EventBridge luôn diễn giải cron theo UTC; biểu thức rate(...) không phụ thuộc múi giờ. Thực hành tốt: viết mọi biểu thức cron theo UTC và chuyển đổi để hiển thị. Nếu phải dùng giờ địa phương, tránh giờ biên giờ tiết kiệm (02:00-03:00 ở hầu hết khu vực); lên lịch lúc 04:00 hoặc sau.