Ekspresi Cron Dijelaskan: Cara Membaca dan Menulis Jadwal Cron

Jika Anda pernah men-deploy aplikasi web, mengonfigurasi pipeline CI/CD, atau mengelola server Linux, Anda hampir pasti pernah menjumpai ekspresi cron. Lima tanda bintang yang menatap Anda dari file konfigurasi. String misterius seperti 0 2 * * 0 yang tersembunyi di dalam workflow GitHub Actions. Jadwal AWS EventBridge yang sudah tidak dipahami siapa pun di tim. Ekspresi cron ada di mana-mana — dan memang membingungkan jika Anda belum meluangkan waktu untuk mempelajari sistemnya.

Panduan ini adalah referensi yang wajib Anda tandai. Mulai dari sejarah cron dan di mana ia muncul dalam infrastruktur modern, hingga setiap karakter khusus, 10 contoh dunia nyata dengan anotasi, kesalahan umum, dan tabel referensi lengkap. Di akhir panduan, Anda akan bisa membaca ekspresi cron apa pun sekilas dan menulis yang baru dengan percaya diri.

Apa Itu Cron?

Cron adalah penjadwal tugas berbasis Unix yang menjalankan perintah atau skrip secara otomatis pada waktu dan interval yang ditentukan. Namanya berasal dari Chronos, personifikasi waktu dalam mitologi Yunani — pilihan yang tepat untuk alat yang seluruh tujuannya adalah otomasi berbasis waktu. Cron asli diperkenalkan pada Unix Version 7 tahun 1979, ditulis oleh Ken Thompson di Bell Labs, dan telah menjadi fitur utama sistem operasi mirip Unix sejak saat itu.

Penjadwal ini bekerja dengan membaca file konfigurasi yang disebut crontab (cron table) — file teks biasa di mana setiap baris mendefinisikan tugas terjadwal. Proses daemon latar belakang (crond) bangun setiap menit, memeriksa semua crontab aktif, dan menjalankan tugas yang jadwalnya cocok dengan waktu saat ini. Ini adalah desain yang sangat sederhana dan tetap tidak berubah secara fundamental selama lebih dari empat dekade.

Di Mana Cron Dijumpai Saat Ini

Cron bukan sekadar peninggalan masa lalu Unix. Sintaks ekspresi cron adalah standar de facto untuk mengekspresikan jadwal berulang di seluruh tumpukan perangkat lunak modern:

• Crontab Linux dan macOS: Kasus penggunaan asli. Jalankan crontab -e di mesin Linux atau macOS mana pun untuk mengedit jadwal cron pribadi Anda.
• GitHub Actions: File workflow menggunakan sintaks cron di bawah trigger schedule: untuk menjalankan pipeline CI/CD secara berulang.
• AWS EventBridge (sebelumnya CloudWatch Events): Memicu fungsi Lambda, task ECS, dan layanan AWS lainnya sesuai jadwal menggunakan varian cron 6-field.
• Kubernetes CronJobs: Resource CronJob menjalankan workload batch di dalam cluster sesuai jadwal cron.
• Pipeline CI/CD: GitLab CI, CircleCI, Jenkins, dan Bitbucket Pipelines semuanya mendukung eksekusi terjadwal menggunakan ekspresi cron.
• Vercel dan Netlify: Kedua platform mendukung fungsi serverless yang dipicu cron untuk tugas seperti invalidasi cache, pengambilan data, dan build malam hari.
• Pemeliharaan database: Ekstensi pg_cron PostgreSQL, MySQL Event Scheduler, dan layanan database terkelola menggunakan sintaks cron untuk vacuum, indexing, dan pekerjaan backup.
• Penjadwal tingkat aplikasi: Library seperti node-cron, APScheduler (Python), Quartz (Java), dan Sidekiq (Ruby) semuanya menggunakan ekspresi cron untuk mendefinisikan background job berulang.

Singkatnya: jika Anda bekerja di bidang pengembangan perangkat lunak atau administrasi sistem, ekspresi cron adalah sesuatu yang akan Anda temui secara rutin. Mempelajarinya sekali akan memberikan manfaat di mana-mana.

Struktur Lima Field

Ekspresi cron standar terdiri dari tepat lima field yang dipisahkan spasi, masing-masing mewakili satuan waktu. Bersama-sama, keduanya mendefinisikan kapan suatu tugas harus dijalankan. Berikut adalah representasi visual kanoniknya:

┌───────────── minute (0–59)
│ ┌─────────── hour (0–23)
│ │ ┌───────── day of month (1–31)
│ │ │ ┌─────── month (1–12)
│ │ │ │ ┌───── day of week (0–7)
│ │ │ │ │
* * * * *

Dibaca dari kiri ke kanan: menit, jam, hari dalam bulan, bulan, hari dalam seminggu. Tanda bintang (*) di field mana pun berarti "setiap nilai yang mungkin untuk field ini." Jadi * * * * * berarti "setiap menit, setiap jam, setiap hari" — jadwal paling permisif yang mungkin.

Field 1: Menit (0–59)

Field menit mengontrol menit mana dalam satu jam tugas dieksekusi. Nilai 0 berarti tepat di awal jam, 30 berarti setengah jam, dan * berarti setiap menit. Ini adalah field paling granular dalam cron standar — unit penjadwalan terkecil adalah satu menit.

Field 2: Jam (0–23)

Field jam menggunakan format 24 jam. 0 adalah tengah malam, 9 adalah pukul 9 pagi, 17 adalah pukul 5 sore, dan 23 adalah pukul 11 malam. Tidak ada AM/PM — semuanya dalam format 24 jam. Perlu diingat bahwa cron selalu berjalan dalam zona waktu server kecuali dikonfigurasi secara eksplisit.

Field 3: Hari dalam Bulan (1–31)

Mengontrol hari mana dalam bulan tugas dijalankan. 1 adalah tanggal pertama, 15 adalah tanggal kelima belas, 31 adalah tanggal tiga puluh satu. Berhati-hatilah dengan nilai seperti 31 — pada bulan dengan jumlah hari lebih sedikit (Februari, April, Juni, dll.), tugas yang dijadwalkan pada tanggal 31 tidak akan berjalan bulan itu. Beberapa implementasi mendukung karakter khusus L yang berarti "hari terakhir bulan" terlepas dari berapa banyak hari yang dimiliki bulan tersebut.

Field 4: Bulan (1–12)

Field bulan menggunakan nilai numerik (1 untuk Januari hingga 12 untuk Desember) atau singkatan tiga huruf (JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC) di sebagian besar implementasi. Tanda bintang berarti "setiap bulan."

Field 5: Hari dalam Seminggu (0–7)

Field ini menentukan hari dalam seminggu tugas harus berjalan. Penomoran di sini adalah sumber kebingungan yang umum: baik 0 maupun 7 mewakili Minggu di sebagian besar implementasi cron (keanehan warisan dari desain Unix asli). Senin adalah 1, Selasa adalah 2, dan Sabtu adalah 6. Singkatan tiga huruf (SUN, MON, TUE, WED, THU, FRI, SAT) didukung di sebagian besar alat cron modern.

Karakter Khusus

Kekuatan nyata ekspresi cron berasal dari enam karakter khusus yang memungkinkan Anda mengekspresikan jadwal kompleks secara ringkas. Memahami ini adalah kunci kefasihan.

* — Wildcard (Setiap Nilai)

Tanda bintang berarti "cocokkan setiap nilai yang mungkin di field ini." Di field menit, * berarti setiap menit (0 hingga 59). Di field bulan, berarti setiap bulan. Ini adalah nilai default "saya tidak peduli field ini."

* * * * *    # Runs every single minute, all day, every day

, — Daftar (Beberapa Nilai)

Koma memisahkan daftar nilai tertentu. Field cocok jika waktu saat ini cocok dengan nilai mana pun dalam daftar. Ini adalah cara menjadwalkan tugas untuk berjalan pada beberapa waktu berbeda tanpa menggunakan rentang.

0 9,13,17 * * *    # Runs at 9:00 AM, 1:00 PM, and 5:00 PM every day
0 0 1,15 * *       # Runs at midnight on the 1st and 15th of every month

- — Rentang (Dari Sampai)

Tanda hubung mendefinisikan rentang nilai inklusif. Field cocok dengan setiap nilai antara awal dan akhir, inklusif. Ini ideal untuk mengekspresikan hal-hal seperti "selama jam kerja" atau "pada hari kerja."

0 9-17 * * *      # Runs at the top of every hour from 9 AM through 5 PM
0 0 * * 1-5       # Runs at midnight every Monday through Friday

/ — Step (Setiap N Unit)

Garis miring ke depan mendefinisikan nilai langkah. */5 berarti "setiap 5 unit mulai dari minimum." Anda juga dapat menggabungkannya dengan rentang: 0-30/10 berarti "setiap 10 unit antara 0 dan 30" (yaitu 0, 10, 20, 30). Step adalah salah satu karakter khusus yang paling sering digunakan.

*/5 * * * *       # Every 5 minutes (0, 5, 10, 15, ... 55)
*/15 * * * *      # Every 15 minutes (0, 15, 30, 45)
0 */6 * * *       # Every 6 hours (0:00, 6:00, 12:00, 18:00)
0/15 * * * *      # Same as */15 — starts from 0, every 15 minutes

L — Terakhir (Hanya Beberapa Implementasi)

Karakter L didukung di beberapa implementasi cron (terutama Quartz Scheduler di Java dan beberapa varian cron Linux) yang berarti "terakhir." Di field day-of-month, L berarti hari terakhir bulan berjalan — baik itu tanggal 28, 29, 30, atau 31. Ini memecahkan masalah penjadwalan tugas "akhir bulan" tanpa mengetahui panjang bulan terlebih dahulu.

0 0 L * *         # Midnight on the last day of every month (Quartz/some crons)

? — Tidak Ada Nilai Spesifik (Quartz/Java Cron)

Tanda tanya digunakan di Quartz Scheduler (Java) dan beberapa alat lainnya ketika Anda ingin menentukan day-of-week tanpa juga menentukan day-of-month, atau sebaliknya. Karena tidak masuk akal secara logis untuk menentukan keduanya (misalnya "tanggal 15 DAN hari Rabu"), salah satunya harus diset ke ? untuk menandakan "tidak peduli." Cron Unix standar tidak menggunakan karakter ini — Anda menggunakan * sebagai gantinya.

0 9 15 * ?        # Quartz: 9 AM on the 15th, day-of-week unspecified
0 9 ? * MON       # Quartz: 9 AM every Monday, day-of-month unspecified

10 Contoh Cron Dunia Nyata

Cara terbaik untuk memantapkan pemahaman Anda adalah mempelajari contoh nyata dengan konteks mengapa setiap jadwal dipilih. Berikut adalah sepuluh pola yang akan Anda temui (dan gunakan) secara rutin.

1. Setiap Hari Kerja Pukul 9:00 Pagi

0 9 * * 1-5

Menit adalah 0 (tepat di awal jam), jam adalah 9 (pukul 9 pagi), day-of-month dan month adalah wildcard, dan day-of-week adalah 1-5 (Senin hingga Jumat). Digunakan untuk pengingat standup harian, email laporan yang dikirim di awal hari kerja, dan tugas sinkronisasi data pagi yang tidak boleh berjalan di akhir pekan.

2. Setiap 15 Menit

*/15 * * * *

Sintaks step */15 di field menit memberikan eksekusi pada menit 0, 15, 30, dan 45 setiap jam, sepanjang waktu. Umum untuk ping health check, pemanasan cache, percobaan ulang webhook, dan tugas polling hampir real-time di mana Anda membutuhkan data segar namun real-time sejati berlebihan atau tidak tersedia.

3. Setiap Hari Tengah Malam

0 0 * * *

Menit 0, jam 0, semua lainnya wildcard. Ini adalah salah satu pola cron paling umum yang ada. Digunakan untuk pembuatan laporan harian, rotasi log, pengarsipan database, pembersihan file sementara, pengiriman email digest harian, dan tugas "sekali sehari" yang harus berjalan di luar jam kerja.

4. Tanggal 1 Setiap Bulan Tengah Malam

0 0 1 * *

Day-of-month adalah 1, semua lainnya wildcard (kecuali menit/jam yang tetap). Ini berjalan pada 1 Januari, 1 Februari, 1 Maret, dan seterusnya. Jadwal utama untuk pembuatan faktur bulanan, pemicu siklus penagihan, pembaruan langganan SaaS, dan roll-up analitik bulanan.

5. Setiap Minggu Pukul 2:00 Dini Hari

0 2 * * 0

Day-of-week 0 adalah Minggu, dan jam 2 adalah pukul 2 dini hari — waktu ketika traffic biasanya paling rendah. Digunakan untuk backup database penuh mingguan, regenerasi sitemap, re-indexing konten untuk pencarian, dan tugas pemrosesan batch berat yang akan memengaruhi performa selama minggu kerja.

6. Hari Kerja Pukul 8:30, 12:30, dan 17:30

30 8,12,17 * * 1-5

Ini menggabungkan daftar di field jam dengan rentang di field day-of-week. Menit 30 berarti dieksekusi di menit ke-30. Digunakan untuk batch notifikasi terjadwal (push notification, email digest), tugas sinkronisasi data tiga kali sehari, dan alur kerja di mana Anda ingin titik kontak rutin sepanjang hari kerja tanpa memukul setiap jam.

7. 1 Januari Tengah Malam

0 0 1 1 *

Day-of-month 1 dan month 1 (Januari) bersama-sama menentukan Tahun Baru. Digunakan untuk tugas tahunan seperti pembaruan langganan tahunan, pengarsipan data tahun sebelumnya, pembuatan laporan kepatuhan tahunan, dan reset kuota atau penghitung tahunan di aplikasi.

8. Setiap 5 Menit Selama Jam Kerja di Hari Kerja

*/5 9-17 * * 1-5

Ekspresi gabungan yang menggabungkan step (*/5), rentang di jam (9-17), dan rentang di day-of-week (1-5). Ini memberikan monitoring atau polling agresif — setiap 5 menit dari pukul 9 pagi hingga 5 sore Senin hingga Jumat — sementara diam semalaman dan di akhir pekan untuk menghemat sumber daya dan menghindari alert fatigue.

9. Setiap 6 Jam

0 */6 * * *

Step di field jam (*/6) memberikan empat eksekusi yang merata per hari: tengah malam, pukul 6 pagi, siang, dan pukul 6 sore. Digunakan untuk sinkronisasi data antar sistem, pembaruan token API atau kredensial OAuth jangka panjang sebelum kedaluwarsa, dan invalidasi cache berkala untuk konten yang berubah beberapa kali sehari namun tidak memerlukan kesegaran tingkat menit.

10. Tanggal 15 dan Hari Terakhir Setiap Bulan

0 0 15,L * *

Daftar koma di field day-of-month yang menggabungkan tanggal tetap (15) dan singkatan hari terakhir (L). Ini adalah jadwal penggajian semi-bulanan klasik — periode gaji yang berakhir pada tanggal 15 dan hari terakhir bulan. Perlu dicatat bahwa L memerlukan implementasi yang mendukungnya (Quartz, beberapa cron Linux); crontab standar tidak mendukung L.

Kesalahan Umum dan Jebakan

Ekspresi cron memiliki beberapa jebakan yang sudah dikenal yang menyebabkan insiden produksi. Memahaminya sejak awal akan menghemat sesi debugging yang menyakitkan di tengah malam.

Penomoran Hari dalam Seminggu Tidak Universal

Sebagian besar implementasi cron Unix memperlakukan baik 0 maupun 7 sebagai Minggu. Namun beberapa alat (termasuk library tingkat aplikasi tertentu) memulai minggu pada Senin, sehingga 1 = Senin dan 7 = Minggu. Selalu verifikasi konvensi penomoran untuk alat spesifik yang Anda gunakan, dan lebih baik menggunakan singkatan tiga huruf (MON, TUE, dll.) ketika implementasi mendukungnya untuk menghilangkan ambiguitas.

Cron Berjalan dalam Zona Waktu Server

Ini mungkin sumber bug cron paling umum di produksi. 0 9 * * * berarti pukul 9 pagi dalam zona waktu mesin yang menjalankan tugas — yang mungkin UTC, US/Eastern, atau lainnya. Selalu dokumentasikan asumsi zona waktu dalam komentar di samping ekspresi cron. Untuk penjadwal berbasis cloud, konfigurasikan zona waktu secara eksplisit jika platform mendukungnya.

# Good practice: always document the timezone
# Runs at 9 AM US/Eastern (UTC-5 or UTC-4 during DST)
0 14 * * 1-5   # 9 AM ET expressed in UTC

Cron GitHub Actions Selalu Berjalan dalam UTC

GitHub Actions menggunakan sintaks cron 5-field standar di bawah kunci on: schedule:, tetapi penjadwal selalu beroperasi dalam UTC — tidak ada opsi konfigurasi zona waktu. Jika Anda ingin tugas berjalan pukul 9 pagi Waktu Timur, Anda perlu menjadwalkannya pada 0 14 * * * (UTC). Perlu juga dicatat bahwa workflow terjadwal GitHub Actions mungkin terlambat hingga 15 menit selama periode permintaan tinggi.

Sintaks Step Berlaku untuk Fieldnya, Bukan Menit

Kesalahan baca yang umum: */5 di field jam berarti setiap 5 jam — bukan setiap 5 menit. Step selalu berlaku untuk unit field tempat ia berada. */5 di field menit adalah setiap 5 menit; di field jam, setiap 5 jam; di field bulan, setiap 5 bulan.

Tugas yang Berjalan Lebih Lama dari Intervalnya Dapat Tumpang Tindih

Cron adalah penjadwal fire-and-forget. Jika Anda menjadwalkan tugas setiap 5 menit dan satu instance tugas membutuhkan waktu 7 menit untuk selesai, instance kedua akan dimulai sementara yang pertama masih berjalan. Ini dapat menyebabkan race condition, pemrosesan duplikat, dan korupsi data. Gunakan file lock atau advisory lock di database Anda untuk mencegah eksekusi bersamaan dari tugas yang sama.

Field yang Dihilangkan vs Wildcard Tidak Selalu Setara

Di beberapa implementasi cron yang diperluas (terutama Quartz), menghilangkan field dan menggunakan* diperlakukan berbeda. Selalu gunakan semua field yang diperlukan secara eksplisit dan jangan pernah mengandalkan nilai default untuk jadwal produksi kritis.

Ekstensi Non-Standar: Cron 6-Field

Cron Unix standar memiliki lima field, dengan menit sebagai granularitas terkecil. Beberapa sistem memperluas ini dengan field tambahan:

Field Detik (Ditempatkan di Depan)

Banyak penjadwal tingkat aplikasi (node-cron, Quartz, Spring Scheduler) menambahkan field detik di awal, memberikan 6 field. Ini memungkinkan penjadwalan sub-menit hingga detik. Field-nya adalah: detik menit jam hari-dalam-bulan bulan hari-dalam-seminggu.

# 6-field cron with seconds prepended (Quartz / node-cron)
0 */5 * * * *    # Every 5 minutes (second=0, minute=*/5, ...)
30 0 9 * * 1-5   # Weekdays at 9:00:30 AM

AWS EventBridge (6 Field dengan Tahun)

AWS EventBridge menggunakan format 6-field di mana field tahun ditambahkan di akhir:menit jam hari-dalam-bulan bulan hari-dalam-seminggu tahun. Juga memerlukan penggunaan ? untuk day-of-month atau day-of-week (tidak boleh keduanya sebagai wildcard secara bersamaan). AWS EventBridge tidak mendukung sintaks step */ dengan cara yang sama seperti cron Unix.

# AWS EventBridge cron format (6 fields, year at end)
cron(0 9 ? * MON-FRI *)    # Weekdays at 9 AM UTC, any year
cron(0 0 1 * ? *)           # First day of every month at midnight

Cara Menggunakan Cron Parser BrowseryTools

Menulis ekspresi cron dari awal adalah satu keahlian — memvalidasi bahwa Anda menulisnya dengan benar adalah keahlian lain. Cron Parser BrowseryTools memudahkan verifikasi ekspresi apa pun sebelum masuk ke produksi.

Tempelkan ekspresi cron 5-field (atau 6-field) apa pun ke dalam alat dan dapatkan secara instan:

• Deskripsi yang mudah dibaca manusia dari jadwal ("Setiap hari kerja pukul 9:00 Pagi") sehingga Anda dapat memverifikasi maksud Anda sesuai ekspresi sekilas.
• 5–10 waktu eksekusi terjadwal berikutnya yang tercantum secara eksplisit, sehingga Anda dapat melihat kapan tepatnya tugas akan dieksekusi dan memastikan tidak ada kejutan.
• Umpan balik instan tentang sintaks tidak valid — berguna jika Anda memiliki typo atau sedang mengerjakan ekspresi yang ditulis orang lain.

Semuanya berjalan sepenuhnya di browser Anda — tidak ada ekspresi yang dikirim ke server mana pun. Ini adalah cara tercepat untuk memeriksa jadwal sebelum deploy ke GitHub Actions, Kubernetes, atau platform lainnya.

Tabel Referensi Ekspresi Cron

Gunakan tabel ini sebagai referensi cepat. Tandai halaman ini dan kembali kapan pun Anda perlu mencari pola atau memverifikasi arti suatu ekspresi.

Validasi Ekspresi Cron Sebelum Deploy

Ekspresi cron ringkas dan powerful, namun kekompaktannya berarti satu typo dapat secara diam-diam menghasilkan jadwal yang sama sekali berbeda. Tugas yang Anda maksudkan berjalan bulanan mungkin berjalan harian. Backup yang Anda maksudkan dipicu setiap Minggu mungkin tidak pernah berjalan sama sekali. Biaya jadwal yang salah di produksi bisa berkisar dari laporan yang terlewat hingga tugas penagihan yang dieksekusi ratusan kali.

Kebiasaan dua menit untuk menempelkan ekspresi Anda ke dalam validator dan meninjau beberapa waktu eksekusi terjadwal berikutnya sebelum deploy adalah salah satu praktik bernilai tertinggi dalam DevOps dan rekayasa backend. Ini menangkap kesalahan sebelum menjadi insiden.