Ekspresi Cron Referensi Praktis Dengan Contoh Nyata

Ekspresi cron adalah lima bidang yang dipisahkan oleh spasi yang memberi tahu pengatur Unix kapan sebuah perintah harus dijalankan. Lima bidang, sejumlah karakter khusus, dan beberapa pola umum — itulah seluruh model mental yang perlu diingat. Referensi ini mencakup sintaksis, karakter yang membingungkan, serta jadwal yang benar-benar digunakan oleh pengembang.

Lima Bidang

Cron standar menggunakan lima bidang posisional:

* * * * *
│ │ │ │ └─ Day of week   (0–7, Sunday = 0 or 7)
│ │ │ └─── Month         (1–12)
│ │ └───── Day of month  (1–31)
│ └─────── Hour          (0–23)
└───────── Minute        (0–59)

AWS EventBridge dan pengatur Quartz di Java menambahkan sebuah detik bidang di awal, sehingga totalnya menjadi enam bidang. Setiap bidang lainnya bergeser ke kanan. Ini membingungkan pengembang yang pindah antar lingkungan — ekspresi Quartz yang dipaste ke crontab standar akan berjalan pada jadwal yang salah tanpa peringatan apa pun.

Gunakan cron POSIX lima bidang kecuali platform Anda secara eksplisit membutuhkan enam bidang.

Karakter Khusus

Karakter	Arti	Contoh
*	Setiap nilai — cocok untuk setiap unit	* * * * * — setiap menit
,	Daftar nilai	0 9,17 * * * — pukul 9 pagi dan pukul 5 sore
-	Jangkauan	0 9-17 * * * — setiap jam dari pukul 9 pagi hingga pukul 5 sore
/	Interval langkah	*/15 * * * * — setiap 15 menit
?	Tidak ada nilai khusus (hanya Quartz/AWS)	0 0 15 * ? — tanggal 15 setiap bulan, hari apa pun
L	Terakhir (hanya Quartz/AWS)	0 0 L * ? — hari terakhir setiap bulan
W	Hari kerja terdekat (hanya Quartz/AWS)	0 0 15W * ? — hari kerja terdekat dengan tanggal 15

Standar crontab hanya mengenali *, ,, -dan /. Jika Anda melihat ?, L, atau W dalam ekspresi, ekspresi tersebut ditulis untuk Quartz atau AWS EventBridge — jangan salin ke crontab Linux tanpa perubahan.

Tabel Referensi: Jadwal yang Digunakan Pengembang

Bagian ini layak dibookmark. Buat dan validasi ekspresi-ekspresi ini dengan Generator Ekspresi Cron IO Tools.

Keterangan	Ekspresi Cron	Catatan
Setiap menit	* * * * *	Sangat jarang sesuai untuk produksi
Setiap 5 menit	*/5 * * * *	Pemeriksaan kesehatan, siklus polling pendek
Setiap 15 menit	*/15 * * * *	Pemanasan cache, sinkronisasi feed
Setiap 30 menit	*/30 * * * *	Sama dengan 0,30 * * * *
Setiap jam (pada jam angka)	0 * * * *	Berjalan pada :00 setiap jam
Setiap 6 jam	0 */6 * * *	Sinkronisasi data, ekspor increment
Setiap hari pukul 00.00 UTC	0 0 * * *	Pemicu batch harian standar
Setiap hari pukul 09.00 UTC	0 9 * * *	Penghasilan laporan pagi
Pada pukul 09.00 hari kerja UTC	0 9 * * 1-5	Pekerjaan hanya pada hari kerja (Sen–Jum)
Pada pukul 08.30 hari kerja UTC	30 8 * * 1-5	Pengiriman laporan sebelum pertemuan
Setiap hari Minggu pukul 02.00	0 2 * * 0	Pemeliharaan mingguan, backup saat off-peak
Hari pertama setiap bulan	0 0 1 * *	Pemrosesan tagihan bulanan, laporan berulang
Pukul 00.00 tanggal 1 Januari	0 0 1 1 *	Pengaturan tahunan, pekerjaan awal tahun

Masalah Waktu

Cron tidak memiliki kesadaran zona waktu. Ia berjalan dalam zona waktu yang ditetapkan pada server — pada kebanyakan sistem Linux, itu adalah UTC. Ini biasanya tidak masalah sampai Anda memiliki pekerjaan yang terkait dengan jam kerja bisnis, atau pengguna di berbagai wilayah yang bertanya mengapa laporan "pukul 9 pagi" tiba pada pukul 14.00.

Default yang paling aman:

• Atur server Anda ke UTC. Konversi ke waktu lokal dalam logika aplikasi, bukan dalam jadwal cron.
• Komentar setiap pekerjaan cron dengan waktu lokal yang efektif, agar orang berikutnya yang membaca crontab tidak harus menebak.
• Ketika menggunakan pengaturan cloud (AWS EventBridge, Google Cloud Scheduler), verifikasi bidang zona waktu — kebanyakan mendukung nama zona waktu IANA secara langsung, yang menghilangkan ketidakjelasan.

# Always comment with the effective local time
# Runs daily at midnight UTC (= 8pm EST / 5pm PST)
0 0 * * * /usr/bin/python3 /opt/scripts/daily_report.py

Pengujian: Hitung Waktu Berikutnya Sebelum Anda Menyematkan

Menyematkan pekerjaan cron ke server dan menemukan bahwa ia berjalan setiap menit bukan setiap jam adalah bagian dari tradisi. Lepaskan hal ini.

Itu Kalkulator Waktu Berikutnya Cron IO Tools menunjukkan tepat waktu ketika ekspresi Anda akan berjalan berikutnya — salin ekspresi Anda dan dapatkan waktu-waktu berikutnya sepuluh kali sebelum menyentuh server.

Untuk validasi di baris perintah:

# Install croniter (Python) for quick expression testing
pip install croniter

python3 -c "
from croniter import croniter
from datetime import datetime

cron = croniter('*/15 * * * *', datetime.utcnow())
for _ in range(5):
    print(cron.get_next(datetime))
"

Menambahkan Pekerjaan Cron di Linux

# Open the crontab editor for the current user
crontab -e

# Format: minute hour day month weekday command
# Run backup script daily at 2:30am UTC
30 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

# Run a Python script every 5 minutes
*/5 * * * * /usr/bin/python3 /home/user/scripts/sync.py

# View current crontab entries
crontab -l

# Edit another user's crontab (requires root)
crontab -u www-data -e

Itu 2>&1 di akhir baris backup mengarahkan stderr ke stdout, sehingga kedua arah masuk ke file log. Tanpa itu, kesalahan cron masuk ke saluran email — dan tidak ada yang memeriksa hal itu.

Pekerjaan Terjadwal GitHub Actions

GitHub Actions menggunakan sintaks cron lima bidang yang sama, selalu dalam UTC. Tidak ada pengganti zona waktu.

name: Nightly Data Export

on:
  schedule:
    # Runs at 1:00 AM UTC every weekday
    - cron: "0 1 * * 1-5"
  workflow_dispatch: # Allow manual trigger

jobs:
  export:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run export script
        run: python scripts/export.py

Satu catatan: Pekerjaan terjadwal GitHub Actions dapat terlambat hingga 15 menit selama periode beban tinggi. Jangan mengandalkan hal ini untuk hal-hal yang membutuhkan waktu yang sangat akurat.

Ketika Cron Tidak Cukup

Cron standar menangani kebanyakan kasus pada satu server. Batasannya menjadi masalah saat skala meningkat:

• Tidak ada pengulangan saat gagal. Jika pekerjaan gagal, waktu berikutnya adalah waktu jadwal berikutnya — tidak ada pengulangan otomatis.
• Tidak ada penguncian terdistribusi. Beberapa server yang menjalankan crontab yang sama akan menjalankan pekerjaan secara bersamaan.
• Tidak ada observabilitas. Tidak ada dashboard bawaan untuk riwayat eksekusi, peringatan kegagalan, atau pemantauan durasi.

Masalah	Alternatif yang Lebih Baik
Logika pengulangan dan antrian pekerjaan	Celery Beat (Python), Sidekiq-Cron (Ruby)
Pengaturan berbasis cloud dengan pengulangan	AWS EventBridge + Lambda, Google Cloud Scheduler
Pemicu pipeline CI/CD	Pengaturan GitHub Actions
Orchestrasi pekerjaan yang dapat diobservasi	Airflow, Prefect, Temporal

Untuk skrip pada satu server, cron masih alat yang tepat — sederhana, andal, dan tidak memiliki ketergantungan. Untuk hal-hal yang membutuhkan jaminan pengulangan, eksekusi terdistribusi, atau visibilitas kegagalan, antrian pekerjaan khusus akan menghasilkan keuntungan secara cepat.

Gunakan Generator Ekspresi Cron untuk membangun jadwal berikutnya tanpa harus menghafal sintaksis, dan Kalkulator Waktu Berikutnya Cron untuk memverifikasi bahwa ekspresi tersebut berjalan saat yang diharapkan.

Anda mungkin juga menyukai