Skip to content

Generator Crontab & Pembuat Ekspresi Cron

Bangun, validasi, dan dekode ekspresi cron di peramban Anda. Pratinjau langsung jadwal berikutnya dalam waktu lokal atau UTC. Sintaksis POSIX 5 kolom, preset, deskripsi bahasa biasa. Gratis, privat, tanpa daftar.

Tanpa Pelacakan Berjalan di Browser Gratis
Seluruh parsing dan perhitungan jadwal berikutnya terjadi secara lokal di peramban Anda. Tidak ada data yang dikirim ke server mana pun.

Kolom
Preset

Bahasa biasa

5 jadwal berikutnya

Zona waktu untuk pratinjau jadwal berikutnya
    Ditinjau untuk kepatuhan POSIX 5 kolom, kebenaran semantik OR, penambatan operator langkah, perluasan token bernama, dan penolakan operator Quartz dengan kesalahan yang membantu — Tim Engineering Go Tools · May 20, 2026

    Apa Itu Ekspresi Cron?

    Ekspresi cron adalah string lima kolom yang mendefinisikan jadwal berulang. Dari kiri ke kanan, kolomnya adalah menit (0-59), jam (0-23), tanggal (1-31), bulan (1-12), dan hari (0-6, di mana 0 dan 7 sama-sama berarti Minggu). Tiap kolom menerima nilai, daftar (`1,3,5`), rentang (`1-5`), wildcard (`*` berarti sembarang nilai), atau langkah (`*/15` berarti tiap 15). Kombinasinya mendefinisikan persis kapan perintah terjadwal akan berjalan — `0 9 * * 1-5` misalnya dibaca "pada menit 0, jam 9, sembarang tanggal, sembarang bulan, hari Senin sampai Jumat" — dalam bahasa biasa, "hari kerja pukul 09.00".

    Cron berasal dari Unix Versi 7 pada 1979 dan tata bahasa lima kolomnya pada dasarnya tidak berubah selama lebih dari empat dekade — bukti betapa baiknya sintaksis asli dirancang. Saat ini ekspresi cron digunakan jauh melampaui file crontab Unix: Kubernetes CronJobs, alur kerja GitHub Actions, aturan AWS EventBridge, pipeline terjadwal GitLab CI, Cloudflare Workers Cron Triggers, dan platform serverless di seluruh awan menerima tata bahasa lima kolom yang sama. Belajar cron sekali berarti mengetahui cara menjadwalkan job di tiap konteks infrastruktur modern.

    Standar POSIX mendefinisikan lima operator: `*` (sembarang nilai), `,` (daftar nilai), `-` (rentang), `/` (langkah), dan token bernama untuk bulan (JAN-DEC) dan hari (SUN-SAT). Sebagian besar implementasi juga memperluas lima singkatan umum: `@yearly` (`0 0 1 1 *`), `@monthly` (`0 0 1 * *`), `@weekly` (`0 0 * * 0`), `@daily` (`0 0 * * *`), dan `@hourly` (`0 * * * *`). Scheduler Quartz (pustaka Java) memperluas ini dengan kolom detik opsional dan operator tambahan (`?`, `L`, `W`, `#`) — berguna jika Anda bekerja di Java/Spring, tetapi tidak portabel ke cron standar. Alat ini mengikuti standar POSIX lima kolom karena merupakan varian dominan dan yang akan sungguh dipahami oleh server Linux, runner GitHub Actions, dan klaster Kubernetes Anda.

    Satu keanehan cron POSIX patut diperhatikan: ketika tanggal dan hari sama-sama dibatasi (tidak ada yang `*`), jadwal berjalan saat SALAH SATU cocok — semantik OR, bukan AND. Jadi `0 0 1 * 5` berjalan pada tanggal 1 setiap bulan DAN setiap hari Jumat, bukan hanya hari Jumat yang kebetulan jatuh pada tanggal 1. Inilah kejutan cron yang paling sering muncul; pratinjau jadwal berikutnya pada alat ini membuatnya jelas terlihat dengan menampilkan datetime aktual yang akan dijalankan. Verifikasi sebelum deploy.

    Seluruh parsing dan perhitungan jadwal berikutnya terjadi sepenuhnya di peramban Anda menggunakan JavaScript — tidak ada ekspresi, jadwal, atau data lain yang pernah dikirim ke server. Alat ini mengurai ekspresi cron POSIX standar apa pun secara seketika dengan deskripsi bahasa biasa dan pratinjau lima jadwal, dengan privasi penuh.

    Ekspresi cron berkaitan erat dengan alat developer lainnya. Cron job umumnya di-debug dengan memeriksa Unix timestamp terhadap waktu jalan yang diharapkan, dan jadwal kompleks sering didokumentasikan sebagai konfigurasi JSON yang dapat divalidasi dengan formatter JSON kami. Untuk panduan mendalam yang mencakup semantik OR, jebakan zona waktu, dan varian cron umum dengan contoh di Linux, Kubernetes, dan GitHub Actions, baca referensi jadwal cron kami.

    # Linux crontab entry — runs every 15 minutes
    */15 * * * *  /usr/local/bin/poll-api.sh
    
    # Kubernetes CronJob — weekdays at 9:00 AM UTC
    apiVersion: batch/v1
    kind: CronJob
    metadata:
      name: daily-report
    spec:
      schedule: "0 9 * * 1-5"
      timeZone: "UTC"
      jobTemplate:
        spec:
          template:
            spec:
              containers:
                - name: report
                  image: report-runner:1.0
              restartPolicy: OnFailure
    
    # GitHub Actions workflow — hourly
    on:
      schedule:
        - cron: '0 * * * *'
    
    # AWS EventBridge — first of each month
    ScheduleExpression: cron(0 0 1 * ? *)
    # (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

    Fitur Utama

    Parser POSIX 5 Kolom Langsung

    Parser ketat yang mengikuti cron POSIX: menit (0-59), jam (0-23), tanggal (1-31), bulan (1-12 atau JAN-DEC), hari (0-6 atau SUN-SAT, dengan 7 juga menerima Minggu). Semua operator standar (`*` `,` `-` `/`) dan makro (`@yearly` `@monthly` `@weekly` `@daily` `@hourly`) didukung.

    Pratinjau 5 Jadwal Berikutnya

    Menghitung lima waktu jadwal berikutnya dari waktu lokal Anda saat ini. Beralih antara Lokal dan UTC dengan satu klik — cara paling andal untuk menangkap kejutan zona waktu sebelum men-deploy crontab ke server di wilayah berbeda.

    Deskripsi Bahasa Biasa

    Setiap ekspresi yang valid mendapat penjelasan yang dapat dibaca manusia: "Tiap 15 menit", "Hari kerja pukul 09.00", "Pada 02.30 tanggal 1, di Januari dan Juli". Mempermudah tinjauan kode dan serah terima tim — tidak perlu menebak apa yang sebenarnya dilakukan `*/5 9-17 * * 1-5`.

    Pesan Kesalahan pada Level Kolom

    Ekspresi yang tidak valid mendapat umpan balik merah seketika dengan kolom yang bermasalah disorot dan kesalahan spesifik: "Kesalahan pada menit: nilai di luar rentang [0, 59]: "60"". Tidak ada lagi kegagalan crontab yang diam-diam, baru ketahuan tiga hari kemudian saat laporan tidak berjalan.

    Chip Preset untuk Jadwal Umum

    Sebelas preset sekali klik mencakup jadwal yang akan Anda gunakan: tiap menit, tiap 5/15 menit, tiap jam, harian tengah malam atau pukul 09.00, hari kerja pukul 09.00, mingguan pada Minggu/Senin, tanggal 1 tiap bulan, dan tahunan. Ketuk, ubah sedikit, kirim.

    Input Pembangun per Kolom

    Jangan menghafal urutan lima kolom — lima input kecil berlabel Menit, Jam, Tanggal, Bulan, Hari memungkinkan Anda menyunting satu posisi pada satu waktu tanpa menjatuhkan nilai atau salah urutan. Ekspresi penuh di atas dibangun ulang secara otomatis.

    Semantik OR POSIX yang Tepat

    Ketika tanggal dan hari sama-sama dibatasi, aturan OR berlaku — `0 0 1 * 5` berjalan tiap tanggal 1 DAN setiap hari Jumat. Pratinjau jadwal berikutnya membuat ini terlihat sebelum Anda deploy; tidak ada lagi panggilan akhir pekan yang mengejutkan.

    Privasi 100% Berbasis Peramban

    Ekspresi cron Anda — yang sering mengungkap pewaktuan infrastruktur dan pola penjadwalan internal — tidak pernah meninggalkan peramban Anda. Tidak ada data yang dikirim ke server mana pun, tidak ada pencatatan, tidak ada analitik. Anda dapat memverifikasinya di tab Network peramban. Aman untuk jadwal produksi dan sistem internal.

    Pesan Kesalahan yang Sadar Quartz

    Jika Anda menempel ekspresi Quartz dengan `?` `L` `W` atau `#`, parser menjelaskan "Operator Quartz tidak didukung — gunakan sintaksis POSIX" sehingga Anda tahu untuk menulis ulang untuk cron alih-alih men-debug kegagalan diam. Jadwal Quartz tidak berjalan di cron Linux.

    Varian Cron & Scheduler

    Vixie cron (default Linux)

    5 kolom POSIX

    Default pada sebagian besar distro Linux. POSIX ketat dengan ekstensi `CRON_TZ=` untuk zona waktu eksplisit. Semantik OR tanggal/hari berlaku. Target utama alat ini.

    BSD cron

    5 kolom POSIX

    Default macOS dan keluarga BSD. Kompatibel POSIX dengan perbedaan implementasi kecil dari vixie cron; sebagian besar ekspresi bekerja identik.

    Timer systemd (OnCalendar)

    spesifikasi kalender, bukan cron

    Alternatif untuk cron pada Linux berbasis systemd. Menggunakan sintaksis `OnCalendar: 2026-*-* 09:00:00` — lebih mudah dibaca untuk jadwal non-berulang tetapi tidak dapat dioperasikan dengan ekspresi cron.

    Quartz Scheduler (Java/Spring)

    6 atau 7 kolom

    Menambahkan kolom detik (wajib) dan tahun (opsional), plus operator `?`, `L`, `W`, `#`. Berguna untuk aplikasi Java tetapi tidak portabel ke cron Linux.

    AWS EventBridge

    6 kolom gaya Quartz dengan `?`

    Mensyaratkan hari atau tanggal menjadi `?` (konvensi Quartz) alih-alih `*` ketika hanya satu yang dibatasi. Ekspresi tidak portabel langsung ke cron Linux.

    Kubernetes CronJob

    5 kolom POSIX + kolom timeZone

    Jadwal POSIX 5 kolom plus kolom `spec.timeZone` (1.27+). Lebih bersih daripada mengandalkan zona waktu host kubelet. Ekspresi portabel langsung dari cron Linux.

    GitHub Actions

    5 kolom POSIX

    Selalu berjalan di UTC. Pewaktuan best-effort — dapat dilewatkan di bawah beban tinggi. Hindari interval lebih pendek dari 15 menit. Ekspresi portabel langsung dari cron Linux.

    Contoh Ekspresi Cron

    Setiap 15 Menit

    */15 * * * *

    Operator langkah: `*/15` di kolom menit berarti "tiap 15 menit mulai dari menit 0" — jadi dijalankan pada :00, :15, :30, :45 tiap jam setiap hari. Interval paling umum untuk polling API, menyegarkan cache, dan pemeriksaan heartbeat.

    Hari Kerja Pukul 09.00

    0 9 * * 1-5

    Rentang `1-5` di kolom hari berarti Senin sampai Jumat (1=Sen, 5=Jum). Dijalankan tepat pukul 09.00 — berguna untuk laporan jam kerja, batch job yang bergantung pada data semalam, dan pengingat standup harian.

    Tanggal 1 Setiap Bulan Tengah Malam

    0 0 1 * *

    Tanggal `1`, semua kolom lebih rendah lainnya nol. Umum untuk penagihan bulanan, rotasi log, dan rekonsiliasi akhir periode. Tanggal dan hari hanya saling membatasi bila tidak ada yang `*` — di sini hari adalah `*` sehingga hanya tanggal yang berlaku.

    Tiap 5 Menit antara Pukul 09.00 dan 17.00, Hari Kerja

    */5 9-17 * * 1-5

    Menggabungkan langkah (`*/5`) dengan rentang (`9-17`) pada kolom berbeda. Berguna untuk pemantauan jam kerja saja atau pengurasan antrean. Total: 12 jalanan/jam × 9 jam × 5 hari = 540 jalanan per minggu kerja.

    Kuartalan: Tanggal 1 Jan, Apr, Jul, Okt Tengah Malam

    0 0 1 JAN,APR,JUL,OCT *

    Nama bulan dalam daftar yang dipisahkan koma. Jadwal kuartalan seperti tutup buku keuangan, tinjauan code-freeze, atau audit kepatuhan. Anda dapat mencampur nama dan angka (`1,APR,7,10` terurai sama), tetapi pertahankan satu gaya demi keterbacaan.

    Jebakan OR POSIX: Tanggal 1 Bulan ATAU Setiap Jumat

    0 0 1 * 5

    Ketika KEDUA kolom tanggal (`1`) DAN hari (`5`) dibatasi, cron POSIX menjalankan job bila SALAH SATU cocok. Jadi ini berjalan pada tanggal 1 setiap bulan DAN setiap hari Jumat — bukan hanya hari Jumat yang jatuh pada tanggal 1. Inilah kejutan cron yang paling sering muncul; pratinjau jadwal berikutnya membuatnya jelas terlihat.

    Setiap Hari Pukul 02.30 (Jendela Lalu Lintas Rendah)

    30 2 * * *

    Nilai spesifik untuk jam dan menit, wildcard di tempat lain. Jendela 02.00-04.00 UTC merupakan konvensi de facto untuk batch job malam karena tidak bertumpang tindih dengan jam kerja wilayah bisnis utama mana pun. Padukan dengan saklar zona waktu UTC untuk memastikan jalan jatuh di tempat yang Anda harapkan.

    Padanan Makro: @daily

    @daily

    Singkatan `@daily` (juga `@midnight`) berkembang menjadi `0 0 * * *` — setiap hari tengah malam. Makro lain: `@yearly` = `0 0 1 1 *`, `@monthly` = `0 0 1 * *`, `@weekly` = `0 0 * * 0`, `@hourly` = `0 * * * *`. Makro lebih ringkas tetapi bentuk lima kolom lebih portabel di seluruh scheduler (mis., beberapa mendukung makro, beberapa tidak).

    Cara Membangun Ekspresi Cron

    1. 1

      Ketik atau tempel ekspresi cron

      Masukkan ekspresi cron lima kolom di kolom masukan di atas (mis., `*/15 * * * *`). Alat mengurai dan memvalidasi saat Anda mengetik — centang hijau untuk valid, kesalahan merah dengan nama kolom untuk yang tidak valid. Makro seperti `@daily`, `@hourly`, dll. juga diterima.

    2. 2

      Atau sesuaikan lima input kolom

      Jangan menghafal urutan kolom — sunting Menit, Jam, Tanggal, Bulan, atau Hari secara individual menggunakan input berlabel. Ekspresi penuh di atas diperbarui secara otomatis. Gunakan `*` untuk wildcard, `*/N` untuk langkah, `a-b` untuk rentang, dan `1,3,5` untuk daftar.

    3. 3

      Pilih preset untuk memulai cepat

      Ketuk chip preset apa pun (Tiap 15 menit, Hari kerja pukul 09.00, dll.) untuk memuat jadwal umum, lalu sesuaikan kolom hingga sesuai kebutuhan. Sebelas preset mencakup pola yang akan Anda gunakan di produksi.

    4. 4

      Verifikasi pratinjau jadwal berikutnya

      Lihat lima datetime jadwal mendatang — beralih antara Lokal dan UTC untuk memastikan jadwal menyala saat Anda inginkan. Inilah cara paling andal untuk menangkap jebakan OR tanggal/hari POSIX sebelum menggigit Anda di produksi.

    5. 5

      Salin dan tempel ke scheduler Anda

      Klik Salin untuk mengambil ekspresi. Tempel ke crontab Anda, timer systemd, `cron:` GitHub Actions, AWS EventBridge, `schedule` Kubernetes CronJob, atau scheduler apa pun yang kompatibel dengan cron. Jangan lupa memverifikasi zona waktu scheduler target — lihat bagian Praktik Terbaik di bawah.

    Kesalahan Cron yang Sering Terjadi

    Jebakan OR POSIX: Kedua Kolom Tanggal/Hari Dibatasi

    Ketika KEDUA kolom tanggal dan hari dibatasi, cron POSIX menjalankan job bila SALAH SATU cocok — bukan keduanya. Jadi `0 0 1 * 5` menyala pada tanggal 1 setiap bulan DAN setiap hari Jumat, bukan hanya hari-Jumat-yang-jatuh-pada-tanggal-1. Gunakan `*` di salah satu dari dua kolom tanggal/hari ketika Anda menginginkan kondisi tunggal, atau tulis skrip wrapper yang melakukan pemeriksaan AND.

    ✗ Salah
    # Maksud: "Jumat pertama dalam bulan"
    0 0 1-7 * 5
    # Sebenarnya: menyala pada tanggal 1-7 ATAU setiap Jumat — kedua kondisi
    ✓ Benar
    # Gunakan wrapper untuk semantik AND yang sebenarnya
    0 0 * * 5  [ $(date +\%d) -le 7 ] && /skrip-anda
    # ATAU jatuhkan satu kondisi dan terima jadwal yang lebih longgar

    Pergeseran Zona Waktu antara Dev dan Prod

    Jadwal cron pada server Linux menggunakan zona waktu sistem, bukan zona waktu lokal penulis. Cron pukul 09.00 pada server yang disetel ke UTC menyala pukul 04.00 US East. Selalu rancang jadwal terhadap zona waktu server target — sebaiknya UTC — dan kunci zona waktu secara eksplisit dengan `CRON_TZ=...` di bagian atas crontab.

    ✗ Salah
    # Ditulis oleh dev US East, di-deploy ke server UTC
    0 9 * * *  /laporan-anda.sh
    # Menyala pukul 09.00 UTC = 04.00 US East — bukan yang dimaksud dev
    ✓ Benar
    # Kunci zona waktu, atau tulis dalam UTC secara eksplisit
    CRON_TZ=America/New_York
    0 9 * * *  /laporan-anda.sh

    Kebingungan Operator Langkah: '*/15' vs '15'

    `*/15` di menit berarti "tiap 15 menit mulai dari 0" (jadi 0, 15, 30, 45). Sekadar `15` berarti "hanya pada menit 15" — satu jalanan per jam. Pemula sering menulis `15` dengan mengira itu tiap 15 menit; deskripsi bahasa biasa pada alat membuat kesalahan tersebut jelas terlihat sebelum deploy.

    ✗ Salah
    # Maksud: tiap 15 menit
    15 * * * *
    # Sebenarnya: sekali per jam, pada menit 15 (4 jalanan/jam lebih sedikit dari yang dimaksud)
    ✓ Benar
    # Benar
    */15 * * * *
    # Tiap 15 menit: menit 0, 15, 30, 45 tiap jam

    Ekspresi Enam Kolom pada Scheduler POSIX

    Quartz/Spring/node-cron mendukung kolom detik opsional sebagai posisi pertama. Crontab Linux, GitHub Actions, AWS EventBridge (sebagian besar), dan Kubernetes CronJob TIDAK — mereka mengharapkan lima kolom. Menempel ekspresi enam kolom diam-diam merusak jadwal: detik Anda menjadi menit, menit menjadi jam, dll.

    ✗ Salah
    # Quartz 6 kolom disalin ke crontab Linux
    0 0 9 * * 1-5
    # Linux membaca: menit=0, jam=0, tanggal=9, bulan=*, hari=1-5
    # = tengah malam pada tanggal 9 di bulan yang cocok dengan hari kerja — kacau
    ✓ Benar
    # POSIX 5 kolom, jatuhkan detik
    0 9 * * 1-5
    # = hari kerja pukul 09.00

    Tanggal di Luar Rentang untuk Bulan

    Cron tidak memvalidasi tanggal terhadap bulan sebenarnya. `0 0 31 2 *` (31 Februari) terurai baik tetapi tidak pernah cocok — Februari paling banyak memiliki 29 hari. Pemula mengira parser akan menangkap ini; tidak. Pratinjau jadwal berikutnya pada alat ini menunjukkan "Tidak ada jadwal mendatang" ketika ekspresi valid secara struktural tetapi mustahil secara logis.

    ✗ Salah
    # 30 atau 31 Februari — tidak pernah berjalan
    0 0 30 2 *
    0 0 31 2 *
    # Terurai tetapi tidak ada jadwal yang pernah menyala
    ✓ Benar
    # Gunakan pola 'hari kerja terakhir Februari' via skrip
    0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /skrip-anda

    Mengira Sintaksis Quartz sebagai POSIX

    Dokumentasi AWS, tutorial Spring, dan banyak jawaban Stack Overflow menunjukkan ekspresi cron Quartz dengan `?`, `L`, `W`, atau `#`. Ini tidak bekerja di crontab Linux. Jika Anda menyalin ekspresi enam kolom dengan `?` pada slot hari, parser Linux akan menolaknya (atau lebih buruk, diam-diam salah urai). Alat ini menangkap operator Quartz dan menjelaskan perbedaannya.

    ✗ Salah
    # Quartz: 'Jumat terakhir bulan' — tidak valid di POSIX
    0 0 ? * 6L *
    ✓ Benar
    # Pendekatan skrip wrapper POSIX untuk Jumat-terakhir
    0 0 25-31 * 5  /skrip-anda
    # Berjalan pada Jumat antara tanggal 25-31 bulan mana pun

    Kasus Penggunaan Umum

    Job Crontab Linux
    Bangun dan verifikasi entri untuk `/etc/crontab`, `/etc/cron.d/*`, atau file `crontab -e` per pengguna. Gunakan pratinjau jadwal berikutnya untuk memastikan jadwal jatuh pada waktu yang tepat di zona waktu server Anda yang dikonfigurasi sebelum menyimpan.
    Jadwal Kubernetes CronJob
    Hasilkan kolom `spec.schedule` untuk Kubernetes CronJob. Kubernetes 1.27+ juga mendukung `spec.timeZone` — gunakan saklar UTC untuk merancang jadwal Anda dalam UTC, lalu setel `timeZone` secara eksplisit untuk menghindari waktu lokal node worker.
    Alur Kerja Terjadwal GitHub Actions
    Bangun entri `cron:` di bawah `on.schedule`. GitHub Actions selalu berjalan di UTC — alihkan pratinjau ke UTC untuk memastikan jadwal Anda. Hindari interval lebih pendek dari 15 menit; scheduler GitHub melewatkan job interval pendek di bawah beban.
    Aturan AWS EventBridge
    Susun ekspresi cron untuk aturan terjadwal EventBridge. Catatan: AWS menggunakan sintaksis enam kolom gaya Quartz dengan `?` untuk hari — alat ini menghasilkan POSIX lima kolom, yang perlu Anda konversi dengan menambahkan detik (`0`) di depan dan mengganti `*` di salah satu kolom tanggal/hari dengan `?`.
    Pipeline Terjadwal GitLab CI
    Verifikasi ekspresi cron untuk pipeline CI terjadwal di GitLab. GitLab menggunakan sintaksis POSIX lima kolom — yang dihasilkan alat ini — dan pemilih tanggal UI, tetapi bentuk cron memberi Anda kontrol lebih halus untuk interval non-standar.
    Cloudflare Workers Cron Triggers
    Bangun entri `[triggers.crons]` di `wrangler.toml`. Cloudflare menggunakan sintaksis POSIX lima kolom. Interval minimum satu menit; worker berjalan di UTC. Gunakan pratinjau untuk memverifikasi trigger menyala dalam jendela yang Anda harapkan.
    Jadwal node-cron Node.js
    Bangun ekspresi untuk pustaka `node-cron`, yang mendukung baik POSIX lima kolom maupun kolom detik di depan yang opsional. Pertahankan lima kolom kecuali Anda secara khusus memerlukan presisi di bawah menit — ekspresi enam kolom tidak portabel ke crontab Linux.
    Tinjauan Kode dan Dokumentasi
    Tempel ekspresi cron dari PR atau runbook untuk langsung melihat apa yang dilakukannya — tidak perlu lagi menebak `30 7 * * 1-5` atau mencari kartu referensi. Deskripsi bahasa biasa juga bagus untuk komentar inline dan file README.

    Referensi Sintaksis Cron

    Urutan Kolom: M J T B H
    Menit (0-59), Jam (0-23), Tanggal (1-31), Bulan (1-12), Hari (0-6, 7 juga = Minggu). Mnemonik: "Menit Jam Tanggal Bulan Hari". Kolom hari menerima baik token numerik (0-6) maupun bernama (SUN-SAT, tidak case-sensitive).
    Operator
    `*` = sembarang nilai; `,` = pemisah daftar (`1,3,5`); `-` = rentang (`1-5`); `/` = langkah (`*/15`, `5/10`); nama: JAN-DEC untuk bulan, SUN-SAT untuk hari (tidak case-sensitive).
    Makro (Alias)
    `@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot` merupakan non-jadwal khusus (hanya berjalan saat boot) dan ditolak dengan kesalahan yang menjelaskan.
    Semantik Hari POSIX (Aturan OR)
    Ketika KEDUA kolom tanggal dan hari dibatasi (tidak ada yang `*`), jadwal berjalan saat SALAH SATU cocok — semantik OR. Ketika hanya satu yang dibatasi, yang itulah yang menentukan. Ketika keduanya `*`, setiap hari cocok. Aturan OR ini berlaku untuk vixie cron, BSD cron, dan sebagian besar implementasi POSIX; Quartz menggunakan `?` untuk membedakan AND vs OR.
    Mode Enam Kolom (Quartz-Lite)
    Jika masukan Anda memiliki enam token yang dipisahkan spasi, alat memperlakukan yang pertama sebagai kolom detik (0-59). Berguna untuk Quartz, Spring `@Scheduled(cron=...)`, dan node-cron. TIDAK portabel ke crontab Linux atau scheduler POSIX — mereka akan memperlakukan detik Anda sebagai menit dan menggeser semuanya satu posisi.
    Penambatan Operator Langkah
    `*/N` ditambatkan ke nilai terendah kolom: `*/15` di menit = `0,15,30,45`, bukan "tiap 15 mulai sekarang". Dengan basis non-wildcard: `5/15` di menit = `5,20,35,50`. Nilai langkah yang tidak membagi rentang kolom secara merata akan melompat di dekat wraparound — ini benar, bukan bug.
    Batas Validasi
    menit ∈ [0,59], jam ∈ [0,23], tanggal ∈ [1,31], bulan ∈ [1,12], hari ∈ [0,7]. Nilai di luar rentang menghasilkan kesalahan pada level kolom. Tanggal TIDAK divalidasi terhadap bulan (`0 0 31 2 *` terurai baik tetapi tidak pernah cocok karena Februari tidak memiliki tanggal 31 — pratinjau jadwal berikutnya akan menunjukkan "Tidak ada jadwal mendatang").
    Operator Quartz Ditolak
    Cron POSIX tidak mendukung `?` (tanpa nilai spesifik), `L` (terakhir), `W` (hari kerja terdekat), atau `#` (hari ke-n) milik Quartz. Alat ini menolaknya dengan pesan jelas "Operator Quartz tidak didukung" alih-alih diam-diam mengurainya sebagai POSIX yang tidak valid. Untuk jadwal Quartz, gunakan alat yang sadar Quartz atau scheduler Spring.
    Batas Tahun pada Pencarian Jadwal Berikutnya
    Perhitungan jadwal berikutnya mencari hingga 4 tahun ke depan; ekspresi yang cocok lebih jarang dari itu (mis., pola "29 Feb") akan menunjukkan "Tidak ada jadwal mendatang dalam 4 tahun ke depan". Ini disengaja untuk menghindari iterasi tak terbatas pada pola yang mustahil.

    Praktik Terbaik untuk Jadwal Cron

    Gunakan UTC di Server, Konversi saat Tampilan
    Setel server Anda ke UTC (`/etc/timezone` atau `TZ=UTC`) dan tulis semua ekspresi cron dalam UTC. Konversi ke waktu lokal hanya saat tampilan di dasbor dan laporan Anda. Ini menghilangkan seluruh kategori bug zona waktu yang menghantam paling keras selama transisi daylight-saving, ketika jadwal waktu lokal diam-diam menyala dua kali atau melewatkan satu jalanan. Gunakan saklar UTC pada alat ini untuk merancang jadwal Anda dalam UTC sejak awal.
    Hindari Jebakan OR Tanggal/Hari POSIX
    Jangan pernah membatasi tanggal DAN hari kecuali Anda menginginkan semantik OR. Jika Anda ingin "setiap Senin di Januari", tulis `0 0 * 1 1` (tanggal adalah `*`); jika Anda ingin "tanggal 1 tiap bulan", tulis `0 0 1 * *` (hari adalah `*`). Aturan OR POSIX berarti `0 0 1 * 1` berjalan tiap tanggal 1 DAN setiap Senin — hampir pasti bukan yang Anda inginkan. Pratinjau jadwal berikutnya akan menangkap ini jika Anda memeriksa sebelum deploy.
    Kunci Zona Waktu Jadwal Secara Eksplisit
    Scheduler modern mendukung penambatan zona waktu dalam definisi jadwal: `CRON_TZ=America/New_York` di bagian atas crontab (vixie cron 3.0+), `spec.timeZone: "America/New_York"` untuk Kubernetes CronJobs 1.27+, ekspresi jadwal dengan `ScheduleExpressionTimezone` untuk AWS EventBridge Scheduler. Kunci zona waktu secara eksplisit alih-alih mengandalkan default server — zona waktu server dapat berubah tanpa peringatan selama migrasi infrastruktur.
    Sebarkan Beban di Antara Menit, Bukan pada :00
    Hindari `0 * * * *` (tiap jam pada menit 0) untuk job non-kritis — pada skala besar, menjadwalkan banyak hal tepat pada :00 menciptakan lonjakan beban. Pilih offset menit acak (`23 * * * *`, `41 * * * *`) untuk tiap job untuk menyebarkan beban. Hal yang sama berlaku untuk job harian: `30 3 * * *` lebih ramah pada basis data Anda dibanding `0 3 * * *` ketika banyak job berkonvergensi pada pukul 03.00.
    Buat Job Idempoten
    Cron tidak memiliki retry bawaan, tidak ada pencegahan tumpang tindih, tidak ada pemulihan jalanan yang terlewat. Job Anda harus aman dijalankan berkali-kali (idempoten) dan memeriksa diri. Alih-alih "kirim laporan pukul 09.00", rancang sebagai "kirim laporan hari ini jika belum terkirim" — ini menyembuhkan diri setelah downtime, jadwal ganda tak sengaja, dan jalanan bersamaan. Idempotensi adalah properti job, bukan scheduler, dan inilah praktik keandalan paling penting.
    Tambahkan Heartbeat untuk Jadwal Kritis
    Mode kegagalan diam cron merupakan kelemahan terbesarnya — jika jadwal tidak menyala, tidak ada yang memberi tahu Anda. Untuk job kritis, minta job melakukan ping layanan heartbeat (Healthchecks.io, Cronitor, Dead Man's Snitch) di akhir tiap jalanan; layanan memperingatkan Anda jika ping yang diharapkan tidak tiba. Ini menangkap baik job yang gagal maupun jadwalnya sendiri yang salah nyala. Tier gratis mencakup sebagian besar kebutuhan personal dan tim kecil.
    Verifikasi dengan Pratinjau Jadwal Berikutnya Sebelum Mengirim
    Sebelum men-deploy jadwal cron baru, lihat lima datetime jadwal mendatang di pratinjau alat ini. Bolak-balik antara Lokal dan UTC. Pastikan jadwal jatuh saat Anda inginkan — bukan lima menit lebih awal, bukan di hari yang salah, bukan melewatkan akhir pekan yang Anda pedulikan. Pratinjau adalah uji produksi yang paling murah.

    Pertanyaan yang Sering Diajukan

    Apa fungsi alat ini?
    Alat ini mengurai, memvalidasi, dan menjelaskan ekspresi cron di peramban Anda, dengan pratinjau langsung lima jadwal berikutnya di zona waktu Anda atau UTC. Ketik ekspresi cron POSIX lima kolom standar apa pun — atau gunakan chip preset dan input per kolom untuk membangunnya tanpa menghafal sintaksis — dan alat ini menghasilkan deskripsi bahasa biasa ("Setiap 15 menit", "Hari kerja pukul 09.00", dll.) plus datetime aktual saat job akan berjalan. Ekspresi yang salah terdeteksi seketika dengan pesan kesalahan pada level kolom sehingga Anda tidak membuang deploy karena jadwal yang rusak. Seluruh alat berjalan 100% di sisi klien: tidak ada yang diunggah, dicatat, atau disimpan — aman untuk crontab produksi dan jadwal internal dengan pola pewaktuan sensitif.
    Apa itu ekspresi cron?
    Ekspresi cron adalah string lima kolom yang mendefinisikan jadwal berulang. Kolomnya adalah menit (0-59), jam (0-23), tanggal (1-31), bulan (1-12), dan hari (0-6, di mana 0 dan 7 sama-sama berarti Minggu). Tiap kolom menerima nilai, daftar (`1,3,5`), rentang (`1-5`), wildcard (`*` = sembarang), atau langkah (`*/15` = setiap 15). Kombinasi kelima kolom mendefinisikan persis kapan perintah terjadwal akan berjalan. Cron berasal dari Unix V7 (1979) dan tetap menjadi bahasa de facto untuk penjadwalan job berbasis waktu di Linux/Unix, dalam orkestrasi kontainer (Kubernetes CronJobs), CI/CD (GitHub Actions, GitLab CI), dan platform serverless (AWS EventBridge, Cloudflare Workers Cron Triggers). Meskipun banyak alternatif telah diusulkan selama beberapa dekade, tidak ada pengganti yang berhasil menggusur tata bahasa cron lima kolom yang ringkas dan ekspresif.
    Apakah data saya diunggah ke mana pun?
    Tidak. Seluruh parsing, validasi, dan perhitungan jadwal berikutnya berjalan 100% di sisi klien di peramban Anda menggunakan JavaScript. Ekspresi Anda tidak pernah dikirim, tidak pernah disimpan di server mana pun, tidak pernah dicatat, dan tidak pernah dianalisis. Hal ini membuat alat aman untuk crontab produksi, pola penjadwalan internal yang mengungkap pewaktuan infrastruktur, dan jadwal sensitif apa pun. Anda dapat memverifikasinya di tab Network peramban — mengetik ekspresi cron memicu nol permintaan jaringan. Alat tidak menggunakan cookie untuk data masukan dan tidak menggunakan analitik pihak ketiga yang akan menangkap apa yang Anda ketik.
    Apa beda cron POSIX dan Quartz?
    Cron POSIX adalah standar lima kolom yang digunakan oleh crontab Unix/Linux, timer systemd, GitHub Actions, GitLab CI, AWS EventBridge, Kubernetes CronJobs, dan kebanyakan scheduler. Quartz adalah pustaka penjadwalan Java yang menambahkan kolom detik (total enam atau tujuh kolom) ditambah operator tambahan: `?` (tanpa nilai spesifik, digunakan ketika tanggal dan hari berkonflik), `L` (terakhir — hari terakhir bulan, Jumat terakhir, dll.), `W` (hari kerja terdekat), dan `#` (hari ke-n dalam bulan, mis., `2#1` = Selasa pertama). Alat ini mengimplementasikan cron POSIX karena jauh lebih banyak digunakan; operator Quartz dilaporkan sebagai kesalahan sintaksis dengan pesan jelas "Operator Quartz tidak didukung". Jika Anda membutuhkan Quartz, scheduler Java populer seperti Quartz Scheduler dan `@Scheduled` Spring adalah target Anda — tetapi definisi jadwalnya tidak portabel langsung ke cron Linux.
    Mengapa '0 0 1 * 5' berjalan tiap hari Jumat DAN tanggal 1?
    Inilah semantik OR tanggal/hari pada cron POSIX, dan ini kejutan cron yang paling sering muncul. Aturannya: ketika KEDUA kolom dibatasi (tidak ada yang `*`), cron menjalankan job bila SALAH SATU kondisi cocok — bukan keduanya. Jadi `0 0 1 * 5` (tanggal=1, hari=5) menyala pada tanggal 1 setiap bulan DAN setiap hari Jumat, bukan hanya hari Jumat yang kebetulan jatuh pada tanggal 1. Jika Anda hanya menginginkan yang terakhir (semantik AND — Jumat-tanggal-1), Anda tidak dapat menyatakannya dalam cron standar; Anda perlu skrip yang berjalan tiap Jumat ATAU tanggal 1 dan keluar lebih awal berdasarkan tanggal aktual. Vixie cron (default GNU/Linux), BSD cron, dan AWS EventBridge semuanya mengikuti aturan OR ini. Pratinjau jadwal berikutnya pada alat ini membuat jadwal aktual terlihat jelas — tempel ekspresi yang mencurigakan dan verifikasi sebelum deploy.
    Bagaimana cara menjalankan job tiap 30 detik?
    Anda tidak bisa, dengan cron POSIX standar. Granularitas minimum cron adalah satu menit — kolom terkecil adalah menit (0-59). Untuk jadwal di bawah satu menit, opsi Anda: (1) Jalankan dua job pada `* * * * *` dan `* * * * *` dengan `sleep 30 &&` di depan salah satunya — kasar tetapi bekerja untuk vixie cron. (2) Gunakan scheduler dengan dukungan detik seperti Quartz, Kubernetes CronJob dengan controller kustom, atau timer systemd dengan `OnCalendar: *-*-* *:*:00/30`. (3) Jalankan daemon long-lived yang tidur 30 detik di antara iterasi — jawaban yang tepat untuk sebagian besar kebutuhan pemantauan. (4) Beralih ke pemicu berbasis event (webhook, antrean pesan) jika Anda benar-benar perlu respons waktu nyata. Pola cron 30 detik hampir selalu menjadi tanda bahwa cron adalah abstraksi yang salah.
    Cron menggunakan zona waktu apa?
    Pada server Linux, vixie cron menggunakan zona waktu sistem — biasanya disetel via `/etc/timezone` atau variabel lingkungan `TZ`. Ini sumber bug yang sering muncul: cron pukul 09.00 di server US East menyala pukul 14.00 UTC, tetapi pada server yang disetel ke UTC menyala pukul 09.00 UTC (yaitu pukul 04.00 East). Perbaikannya yaitu selalu setel server Anda ke UTC dan tulis semua ekspresi cron dalam UTC, atau setel variabel `CRON_TZ=America/New_York` di bagian atas crontab untuk mengunci zona waktu secara eksplisit (didukung oleh vixie cron 3.0+). Scheduler terkelola bervariasi: GitHub Actions selalu berjalan UTC, AWS EventBridge mendukung zona waktu dalam definisi jadwal, Kubernetes CronJob menambahkan kolom `spec.timeZone` di 1.27+. Saklar UTC/Lokal alat ini memungkinkan Anda meninjau jadwal di salah satu zona waktu — bolak-balik untuk memastikan jalan jatuh di tempat yang Anda inginkan.
    Sebenarnya '*/15' diperluas menjadi apa?
    Operator langkah `*/N` berarti "tiap N mulai dari nilai valid terendah pada kolom". Untuk menit (rentang 0-59), `*/15` diperluas menjadi `0,15,30,45` — empat jalanan per jam pada seperempat jam. Langkah BUKAN "tiap 15 menit dari waktu saat ini"; ia berlabuh pada nilai awal kolom. Logika sama untuk kolom lain: `*/2` di jam berarti `0,2,4,...,22` (12 jalanan); `*/3` di tanggal berarti `1,4,7,...,31` (11 jalanan). Untuk basis langkah non-wildcard (mis., `5/15`), perluasannya dari basis: `5/15` di menit = `5,20,35,50`. Nilai langkah yang tidak membagi rentang secara merata akan melompat di dekat wraparound — ini perilaku cron yang benar, bukan bug. Pratinjau jadwal berikutnya membuat jadwal aktual terlihat jelas.
    Bisakah saya menggunakan ekspresi enam kolom dengan detik?
    Ekspresi enam kolom dengan kolom detik di depan (rentang 0-59) adalah ekstensi Quartz/Spring/Cron4j, bukan POSIX. Alat ini menerima ekspresi enam kolom ketika masukan memiliki tepat enam token yang dipisahkan spasi — berguna jika Anda menargetkan Quartz, Spring `@Scheduled(cron=...)`, atau pustaka Node.js seperti `node-cron` yang mendukung detik. Untuk scheduler POSIX standar (Linux crontab, GitHub Actions, AWS EventBridge, Kubernetes CronJob), pertahankan lima kolom — menambahkan kolom detik di depan akan secara diam-diam merusak jadwal (scheduler akan menafsirkan menit Anda sebagai detik, jam Anda sebagai menit, dll., menggeser semuanya satu kolom). Saat ragu, periksa dokumentasi scheduler target Anda; jika tidak secara eksplisit menyatakan "enam kolom dengan detik didukung", gunakan lima kolom.
    Berapa interval maksimum yang dapat dinyatakan cron?
    Tanpa state eksternal, cron dapat mengekspresikan hingga sekali per tahun secara andal dengan `0 0 D M *` (mis., `0 0 1 1 *` = setiap 1 Januari tengah malam). Untuk "tiap dua tahun" atau interval yang lebih panjang, cron saja tidak cukup — Anda perlu pemeriksaan tanggal eksternal di bagian atas skrip Anda (mis., `[ $(($(date +%Y) % 2)) -eq 0 ] && /perintah-anda` untuk berjalan pada tahun genap). Untuk "tiap 90 hari" atau interval multi-hari non-aligned lainnya, cron juga gagal: tidak ada operator modulo-hari bawaan, jadi Anda akan menulis wrapper yang memeriksa hari-dalam-tahun terhadap tanggal acuan. Jika kebutuhan penjadwalan Anda serumit ini, pertimbangkan scheduler workflow sungguhan (Airflow, Temporal, AWS Step Functions) — tata bahasa cron sengaja sederhana dan rusak untuk apa pun di luar pola mingguan/bulanan biasa.
    Bagaimana menangani jalanan yang terlewat setelah downtime?
    Cron standar tidak memiliki pemulihan — jika sistem mati pada waktu terjadwal, jalanan tersebut hanya dilewatkan. Tidak ada catatan "kita melewatkan yang ini". Untuk job kritis, Anda memiliki tiga opsi: (1) Gunakan `anacron` (atau `systemd-cron` dengan `Persistent=true`), yang mengejar job yang terlewat setelah boot, cocok untuk laptop dan sistem yang menyala-mati. (2) Beralih ke scheduler dengan retry bawaan: Kubernetes CronJobs memiliki `startingDeadlineSeconds` (jalankan jika keterlambatan dalam batas tenggat) dan `concurrencyPolicy` (menghindari jalanan yang tumpang tindih); AWS EventBridge mendukung kebijakan retry. (3) Bangun idempotensi ke dalam job itu sendiri: alih-alih "kirim laporan pukul 09.00", buat job menanyakan "sudahkah laporan hari ini dibuat?" dan produksi bila belum — ini menyembuhkan diri setelah berapa pun lamanya downtime. Opsi 3 paling kokoh dan bekerja dengan scheduler apa pun.
    Mengapa cron GitHub Actions saya tidak berjalan tepat waktu?
    Jadwal GitHub Actions bersifat best-effort: mereka dapat menyala terlambat hingga beberapa menit di bawah beban tinggi pada infrastruktur GitHub, dan saat beban sangat tinggi mereka bahkan mungkin dilewatkan sepenuhnya (terutama untuk interval pendek seperti tiap lima menit). Disclaimer yang sama berlaku untuk sebagian besar scheduler terkelola — mereka menukar pewaktuan yang persis demi skala dan keandalan. Implikasi praktis: (1) Jangan menjadwalkan hal yang harus berjalan pada detik yang persis; cron untuk "kira-kira pada waktu ini, setiap hari". (2) Untuk interval pendek, lebih baik worker long-lived daripada job terjadwal. (3) Untuk cutoff keuangan atau kepatuhan yang harus tepat waktu, gunakan daemon cron khusus pada server yang Anda kontrol, atau scheduler lebih ketat seperti AWS EventBridge Scheduler dengan jadwal Standard. (4) Khusus GitHub Actions: hindari interval lebih pendek dari 15 menit; scheduler akan sering melewatkannya di bawah beban.