Cron Ekspresi Penjelasan

Tempel ekspresi cron dan pahami persis apa yang dilakukannya.

Contoh umum

Cara membaca ekspresi cron

Ekspresi cron standar memiliki 5 kolom yang dipisahkan oleh spasi:

menit jam hari bulan hari-pekan

* · nilai apa pun   */n · setiap n unit   1,5 · pada nilai 1 dan 5   1-5 · rentang dari 1 hingga 5

Rentang: menit (0-59), jam (0-23), hari (1-31), bulan (1-12), hari dalam pekan (0-6, 0 = Minggu)

Cara kerjanya

  1. Masukkan ekspresi cron: tempel string cron 5 atau 6 kolom seperti 0 9 * * 1-5.
  2. Baca penjelasan dalam bahasa biasa: alat segera menampilkan deskripsi yang dapat dibaca tentang kapan tugas dijalankan.
  3. Lihat eksekusi berikutnya: daftar 5 hingga 10 eksekusi terjadwal berikutnya ditampilkan dari tanggal dan waktu saat ini.
  4. Validasi: ekspresi yang tidak valid disorot dengan pesan kesalahan tepat yang menjelaskan masalahnya.

Setengah Abad Tick Satu-Menit

Cron adalah scheduler tertua yang masih digunakan harian secara berkelanjutan di sebagian besar server dunia. Penampilan pertamanya dalam catatan sejarah adalah Mei 1975, ketika versi awal dikirim dari AT&T Bell Laboratories sebagai bagian dari cabang Research Unix. Namanya adalah penghormatan kepada Chronos, personifikasi waktu Yunani, dan desainnya telah menua dengan keanggunan aneh: lima bidang yang dipisahkan-spasi yang sama yang diketik insinyur Bell Labs ke /usr/lib/crontab di pertengahan 1970-an masih menggerakkan Kubernetes CronJobs, jadwal GitHub Actions, dan backup database malam pada server pribadi virtual di suatu tempat di Frankfurt sekarang. Implementasi 1975 minimal: ada satu crontab, dimiliki oleh root, melayani seluruh mesin. Jika pengguna ingin pekerjaan berulang, mereka meminta administrator menambahkan baris dengan tangan. Cron melakukan perjalanan ke dunia yang lebih luas dalam Unix Versi 7, dirilis pada 1979. Robert Brown dan Keith Williamson di Purdue University memperluas cron untuk menangani banyak pengguna pada akhir 1979, memperkenalkan alur kerja crontab -e per-pengguna. Penulisan ulang yang menentukan datang ketika Paul Vixie merilis vixie-cron 1.0 pada 6 Mei 1987; vixie-cron memformalkan karakter khusus dan memperkenalkan shortcut @reboot, @hourly, @daily, @weekly, @monthly, @yearly. Vixie 3.0 (27 Desember 1993) menambahkan nilai langkah (/) dan dikirim, dengan patch kecil, ke hampir setiap distribusi Linux dan BSD pada era itu. POSIX mengejar pada 1992 (IEEE Std 1003.2-1992). Setiap keanehan cron modern: penomoran Minggu off-by-one, bug union-vs-intersection bidang-hari: adalah bekas luka dari evolusi ini; tidak ada yang dirancang dalam satu duduk.

Anatomi Ekspresi Lima-Bidang

Ekspresi cron standar adalah lima bidang yang dipisahkan spasi. Dibaca dari kiri ke kanan, mereka bertanya: menit mana, dari jam mana, dari hari-bulan mana, dari bulan mana, dari hari-minggu mana? Rentang yang tepat tidak dapat dinegosiasikan dalam POSIX cron: menit 0-59, jam 0-23, hari-bulan 1-31, bulan 1-12, hari-minggu 0-7 dengan baik 0 maupun 7 mewakili Minggu. Setiap bidang menerima lima operator yang berkomposisi secara bebas: * berarti setiap nilai yang valid; , memisahkan daftar nilai diskrit (0,15,30,45 * * * * berjalan di awal, seperempat lewat, setengah lewat, dan tiga-perempat lewat setiap jam); - adalah rentang inklusif (9-17 di bidang jam berarti 9, 10, 11, 12, 13, 14, 15, 16, 17); / adalah nilai langkah (*/15 di bidang menit berarti setiap menit kelima belas mulai dari nol, yaitu 0, 15, 30, 45). Bulan dan hari-minggu juga dapat ditulis sebagai singkatan tiga-huruf: JAN-DEC dan SUN-SAT. Contoh yang dikerjakan: */15 9-17 * * 1-5 didekode sebagai setiap lima belas menit selama jam 9 hingga 17 inklusif, pada setiap hari dalam bulan, setiap bulan dalam tahun, Senin hingga Jumat: "setiap seperempat-jam selama jam kerja pada hari kerja."

Perangkap Hari-Bulan / Hari-Minggu

Keanehan cron yang paling konsekuensial: yang telah menyebabkan outage, backup yang terlewat, dan invoice yang salah secara diam-diam dalam produksi selama tiga puluh lima tahun: adalah cara cron menggabungkan bidang hari-bulan dan hari-minggu ketika keduanya dibatasi. Bahasa POSIX luar biasa tepat di sini: "jika baik 'hari dalam bulan' (bidang 3) maupun 'hari dalam minggu' (bidang 5) dibatasi (tidak berisi '*'), maka satu atau keduanya harus cocok dengan hari saat ini." Dengan kata lain, ketika tidak ada bidang yang berwildcard, cron mengambil union dari keduanya: pekerjaan berjalan pada hari apa pun yang cocok dengan kedua pembatasan. Ini kebalikan dari yang diasumsikan sebagian besar pengguna. Membaca 0 0 13 * 5 dengan keras: "tengah malam pada tanggal 13, pada hari Jumat": secara alami terdengar seperti persimpangan: hanya Jumat tanggal 13. Dalam vixie-cron dan turunannya itu sebenarnya berarti "setiap tanggal 13 dalam bulan dan setiap Jumat," menembak sekitar sembilan kali sebulan. Lebih buruk, vixie-cron memutuskan apakah akan menggunakan union atau intersection dengan memeriksa hanya karakter pertama dari setiap bidang hari. Paul Vixie sendiri mengakui perilaku ini sebagai bug tetapi menolak untuk mengubahnya, mencatat bahwa memperbaikinya akan melanggar prinsip kekagetan-paling-sedikit: jutaan crontab sudah ditulis dengan asumsi bahwa perilaku yang ada disengaja. Bug karenanya sekarang menjadi fitur, abadi dan menyebar. Model mental pragmatis: jika Anda menemukan diri Anda membatasi baik hari-bulan maupun hari-minggu dan Anda benar-benar menginginkan persimpangan (mis. "Selasa kedua setiap bulan"), gunakan operator # dalam implementasi yang mendukungnya (Quartz, cronie dengan ekstensi): 0 12 ? * 2#2. Dalam POSIX cron murni, persimpangan benar-benar mustahil untuk diekspresikan dalam satu ekspresi dan Anda harus memfilter di dalam skrip yang dijalankan pekerjaan cron.

Makro Shortcut

Shortcut ini bukan POSIX. Lingkungan POSIX-only yang ketat akan menolak @daily; dalam praktik setiap implementasi cron yang mungkin ditemui pembaca (vixie-cron, cronie, fcron, ISC cron, image container) mendukungnya.

Dialek: Standar vs Quartz vs AWS vs K8s vs systemd

"Ekspresi cron" sekarang adalah keluarga kecil dialek yang saling tidak kompatibel. Cron 5-bidang standar (POSIX, vixie-cron, cronie): menit jam hari-bulan bulan hari-minggu: penyebut umum terendah universal. Quartz Scheduler (6 atau 7 bidang, ekosistem Java): detik menit jam hari-bulan bulan hari-minggu [tahun]; memperkenalkan ?, L (last), W (weekday), # (n-th weekday of month). @Scheduled Spring dan Spring Boot menggunakan Quartz. Kubernetes CronJob menggunakan cron 5-bidang standar, dengan bidang spec.timeZone terpisah yang menjadi GA di K8s 1.27 (sumber daya CronJob sendiri adalah GA di 1.21, April 2021); format zona waktu adalah database tz IANA (Europe/Berlin, America/New_York). Jadwal cron GitHub Actions menggunakan cron POSIX 5-bidang dan berjalan dalam UTC. AWS EventBridge cron menggunakan 6 bidang (menit jam hari-bulan bulan hari-minggu tahun), memerlukan operator ? pada salah satu hari-bulan atau hari-minggu (Anda tidak dapat membatasi keduanya), dan menggunakan 1-7 dengan SUN=1: berarti ekspresi EventBridge 0 12 ? * 2 * berjalan tengah hari pada Senin, bukan Selasa. Timer systemd menggunakan sintaks yang sama sekali berbeda (OnCalendar=*-*-* 02:00:00) dan secara bertahap menggantikan cron pada Linux modern untuk penjadwalan tingkat-sistem, meskipun keduanya dikirim berdampingan pada setiap distro utama. Cloud Scheduler (Google Cloud) menggunakan cron 5-bidang standar dengan konfigurasi zona waktu eksplisit. Menerjemahkan ekspresi antar platform memerlukan perhatian yang cermat: jadwal EventBridge yang ditempel akan berjalan pada hari-minggu yang salah di vixie-cron karena pergeseran penomoran hari-minggu.

Pola Umum yang Layak Dihafal

Trik Umum

Zona waktu. cron menggunakan waktu lokal sistem secara default: mengejutkan pada mesin cloud yang default ke UTC. Pekerjaan cron jam 9 pagi pada server UTC berjalan pada jam 4 pagi Eastern. Scheduler modern (Kubernetes 1.27+, AWS EventBridge, Cloud Scheduler) menambahkan bidang zona waktu eksplisit; cron klasik tidak. Aturan "*/N dimulai dari 0". */15 adalah 0, 15, 30, 45: bukan 5, 20, 35, 50. Untuk mulai dari offset bukan-nol Anda harus mendaftarkan (5,20,35,50) atau menggunakan sintaks 5/15 Quartz-saja. Perangkap penumpukan 60-menit. Pekerjaan yang membutuhkan waktu lebih lama dari interval jadwalnya dapat menumpuk: tiga backup 30-menit yang berjalan setiap 15 menit akan tumpang tindih. Mitigasi standarnya adalah flock(1): * * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/myjob memastikan hanya satu instance berjalan pada satu waktu; flag -n membuat akuisisi lock non-blocking, sehingga invokasi berikutnya keluar secara diam-diam alih-alih mengantri. Anomali DST. Pekerjaan cron yang dijadwalkan untuk 02:30 akan berjalan dua kali pada hari jam mundur dan tidak sama sekali pada hari jam maju. cron tidak memiliki konsep "waktu wall-clock yang memperhitungkan DST"; jika jadwal Anda harus melewati transisi DST, sandarkan ke jam yang tidak terpengaruh (jam 3 pagi atau lebih lambat di sebagian besar zona waktu) atau gunakan scheduler yang memahami semantik zona waktu. Pelucutan PATH. Pekerjaan cron berjalan dengan PATH minimal (/usr/bin:/bin) dan lingkungan yang hampir kosong; skrip yang berfungsi di shell interaktif Anda mungkin gagal di cron karena node, python3, atau aws tidak ada di PATH yang diwariskan. Atur PATH= di bagian atas crontab atau gunakan jalur absolut dalam perintah cron. Email overflow. Secara default cron mengirim email output dari setiap pekerjaan ke kotak surat lokal pengguna; pada server tanpa email yang dikonfigurasi ini secara diam-diam mengisi /var/spool/mail hingga disk habis. Atau redirect output (>/dev/null 2>&1), atur MAILTO="" di bagian atas crontab, atau benar-benar konfigurasikan forwarder email.

Alternatif Modern: Kapan Mencari Sesuatu yang Lain

cron sangat baik untuk tugas berulang sederhana pada satu mesin. Itu buruk pada: penjadwalan terdistribusi (pekerjaan yang sama dipicu sekali di seluruh armada alih-alih sekali per mesin), trigger event-driven (jalankan ketika antrian menerima pesan, bukan pada jam), monitoring (cron diam-diam gagal jika pekerjaan keluar bukan-nol kecuali Anda mengatur penerusan email), retry (tidak ada mekanisme built-in: pekerjaan yang gagal berjalan lagi pada siklus berikutnya dan mengakumulasi status), dan dependensi (jalankan pekerjaan B hanya setelah pekerjaan A selesai dengan sukses). Untuk kasus tersebut jawaban modern adalah salah satu dari: Kubernetes CronJob (penjadwalan cluster-aware dengan kebijakan retry dan paralelisme), AWS EventBridge + Lambda atau Step Functions (event-driven dengan observabilitas built-in), Apache Airflow atau Prefect (orkestrasi alur kerja berbasis-DAG dengan dependensi eksplisit), Temporal (eksekusi alur kerja yang tahan lama), healthchecks.io ("saklar dead man's" yang ping Anda ketika pekerjaan cron tidak berjalan sesuai jadwal). Untuk pekerjaan berulang satu-mesin di 2026, cron biasa masih merupakan jawaban yang tepat; untuk yang lain, salah satu alternatif sepadan dengan setup tambahan.

Pertanyaan yang Sering Diajukan

Apa arti * dalam ekspresi cron?

Asterisk (*) dalam bidang cron berarti "setiap nilai yang valid": setiap menit, setiap jam, setiap hari, setiap bulan, setiap hari-minggu. * * * * * berjalan setiap menit setiap hari. Asterisk juga khusus dalam bidang hari-bulan dan hari-minggu karena perangkap union-vs-intersection: ketika salah satu bidang hari memiliki * di awal, vixie-cron menggunakan mode persimpangan; ketika tidak ada, menggunakan mode union dan berjalan pada union dari kedua pembatasan.

Bagaimana saya menjalankan pekerjaan cron setiap 15 menit?

Gunakan notasi langkah: */15 * * * * berjalan setiap 15 menit: pada xx:00, xx:15, xx:30, dan xx:45. Perhatikan bahwa */N selalu dimulai dari 0; Anda tidak dapat menggunakan */15 untuk berarti "setiap 15 menit mulai dari menit 5": untuk itu Anda akan menulis 5,20,35,50 * * * *. Cron dialek-Quartz mendukung 5/15 sebagai alternatif non-standar.

Apa perbedaan antara cron dan at?

cron menjalankan pekerjaan pada jadwal berulang (setiap menit, harian, mingguan). Perintah at menjadwalkan pekerjaan satu-kali untuk berjalan pada waktu masa depan tertentu: at 14:30 tomorrow antrekan pekerjaan untuk satu momen tunggal itu. Gunakan cron untuk tugas berulang dan at untuk eksekusi masa depan satu-kali. Keduanya turun dari garis keturunan Bell Labs / vixie-cron yang sama dan akhirnya dilipat ke daemon yang sama pada sebagian besar sistem.

Mengapa pekerjaan cron saya tidak cocok dengan yang saya harapkan?

Lima penyebab paling umum, dalam urutan frekuensi yang kasar: (1) Kebingungan hari-bulan vs hari-minggu: cron menggunakan union dari keduanya ketika keduanya dibatasi, bukan persimpangan. (2) Zona waktu: cron menggunakan waktu lokal server secara default, sering UTC pada mesin cloud. (3) Masalah PATH: PATH shell interaktif Anda tidak diwariskan, sehingga perintah yang berfungsi di prompt mungkin gagal di cron. (4) Perangkap */N selalu-mulai-dari-0. (5) Output tidak ditangkap di mana pun: pekerjaan yang gagal menghilang secara diam-diam jika Anda belum mengatur email atau mengarahkan output ke file log. Panel "10 jadwal berikutnya" penjelas ini adalah cara termurah untuk memverifikasi apa arti ekspresi Anda sebelum men-deploy.

Apakah ini mendukung format cron non-standar?

Ini menangani POSIX/vixie-cron 5-bidang standar, varian Quartz/Spring 6-bidang dengan detik, dan string khusus @hourly, @daily, @weekly, @monthly, @yearly, dan @reboot. Itu tidak menangani ekstensi Quartz penuh (L, W, #) atau penomoran weekday 1-based AWS EventBridge: untuk itu, gunakan validator platform itu sendiri sebelum men-deploy.

Apakah ekspresi cron saya dikirim ke mana pun?

Tidak. Parsing dan penjelasan berjalan sepenuhnya di browser Anda melalui JavaScript. Ekspresi yang ditempel tidak pernah melintasi jaringan: verifikasi di tab Network DevTools saat Anda mengklik Explain. Aman untuk ekspresi cron dalam config CI produksi, kode infrastruktur, dan runbook operasional di mana jadwal itu sendiri mungkin sensitif (mis. jadwal ekspor database malam yang mengisyaratkan jendela downtime).

Alat terkait