Crontab Guru

ตารางสรุปฟิลด์

 ┌───────────── นาที (0-59)
 │ ┌─────────── ชั่วโมง (0-23)
 │ │ ┌───────── วันที่ของเดือน (1-31)
 │ │ │ ┌─────── เดือน (1-12 หรือ JAN-DEC)
 │ │ │ │ ┌───── วันในสัปดาห์ (0-6 หรือ SUN-SAT; อาทิตย์ = 0 หรือ 7)
 │ │ │ │ │
 * * * * *

ตัวดำเนินการในนิพจน์ cron

ลำดับการอ่านสำคัญ

0 */2 * * 1-5 อ่านจากซ้ายไปขวาว่า: นาทีที่ 0, ทุก 2 ชั่วโมง, วันใดก็ได้ของเดือน, เดือนใดก็ได้, วันจันทร์ถึงวันศุกร์ คนเรามักอ่านฟิลด์จากขวาไปซ้ายตามความเคยชินจนสับสน ให้เริ่มจาก “นาที” เสมอ

กับดัก “ทุก X นาที”

*/10 * * * * จะทำงานในนาทีที่ 0, 10, 20, 30, 40, 50 ไม่ใช่ “ทุก 10 นาทีนับจากตอนที่สร้างงาน” สเต็ปของ cron จะนับจากจุดเริ่มต้นของช่วงค่าในฟิลด์เสมอ หากคุณดีพลอยงานในเวลา 12:03 การทำงานครั้งแรกจะเกิดขึ้นที่ 12:10 ไม่ใช่ 12:13

สำหรับงานที่ต้องการ “N นาทีหลังจากการทำงานครั้งล่าสุด” จริง ๆ ให้ใช้ตัวจัดตารางที่มีตัวจับเวลาแบบถาวร (systemd timers ที่ใช้ OnUnitActiveSec หรือการจัดตารางในระดับแอปพลิเคชันที่เก็บเวลาทำงานครั้งล่าสุดไว้)

กับดักของ cron ที่น่ารู้

• ตั้งทั้งวันที่ของเดือนและวันในสัปดาห์พร้อมกัน: การใช้งาน cron ส่วนใหญ่ถือว่าเป็นแบบ OR ซึ่งมักไม่ใช่สิ่งที่คุณต้องการ
• สเต็ปเป็น 0: */0 ใช้ไม่ได้
• ช่วงที่คาบเกี่ยวข้ามวัน: 22-2 สำหรับชั่วโมงใช้ไม่ได้ใน cron แบบดั้งเดิม ให้ใช้ 22-23,0-2
• 30 กุมภาพันธ์: ตารางอย่าง 0 0 30 2 * จะไม่ทำงานเลย
• ความกำกวมของ DST: งานที่ตั้งไว้ระหว่างตี 2 ถึงตี 3 อาจทำงานสองครั้งหรือไม่ทำงานเลยในวันที่มีการเปลี่ยนเวลาออมแสง (DST)

cron เทียบกับตัวจัดตารางสมัยใหม่

cron ของ Unix ยังถูกใช้อยู่ทั่วไป แต่สำหรับงานสำคัญ คุณน่าจะต้องการสิ่งเหล่านี้:

• systemd timers: ตามจับการทำงานที่พลาดไป รองรับการสุ่มเลื่อนเวลา และอ่านค่าจากไฟล์ยูนิต
• Kubernetes CronJob: เชิงประกาศ (declarative) รองรับการลองใหม่ และรับรู้เขตเวลาในเวอร์ชัน 1.25 ขึ้นไป
• Airflow / Prefect / Dagster: สำหรับงานที่มีการพึ่งพากัน การลองใหม่ การเติมข้อมูลย้อนหลัง และการสังเกตการณ์
• GitHub Actions schedule: cron แบบ 5 ฟิลด์ ใช้ UTC เท่านั้น ช่วงต่ำสุด 5 นาที และส่งแบบ best-effort

ตัว cron เองเป็นรูปแบบที่ยอดเยี่ยม แต่เป็นตัวจัดตารางที่ไม่เหมาะกับงานที่ห้ามพลาด