Skip to content

Crontab Oluşturucu ve Cron İfadesi Üretici

Cron ifadelerini tarayıcıda oluşturun, doğrulayın ve çözümleyin. Yerel saatte veya UTC olarak canlı çalışma önizlemesi. POSIX 5 alanlı söz dizimi, hazır şablonlar ve sade açıklama. Ücretsiz ve gizli.

Takip Yok Tarayıcıda Çalışır Ücretsiz
Tüm çözümleme ve sonraki çalışma hesaplaması yerel olarak tarayıcınızda gerçekleşir. Hiçbir sunucuya veri gönderilmez.

Alanlar
Hazır Şablonlar

Sade Türkçe

Sonraki 5 planlı çalıştırma

Sonraki çalışma önizlemesi için saat dilimi
    POSIX 5 alanlı uyumluluğu, VEYA semantiği doğruluğu, adım operatörü sabitlemesi, adlandırılmış belirteç açılımı ve yardımcı hatalarla Quartz operatörü reddi için incelendi — Go Tools Mühendislik Ekibi · May 20, 2026

    Cron İfadesi Nedir?

    Cron ifadesi, tekrarlayan bir zamanlamayı tanımlayan beş alanlı bir karakter dizisidir. Soldan sağa alanlar şunlardır: dakika (0-59), saat (0-23), ayın günü (1-31), ay (1-12) ve haftanın günü (0-6; burada 0 ve 7 her ikisi de Pazar anlamına gelir). Her alan; bir değer, bir liste (`1,3,5`), bir aralık (`1-5`), bir joker (`*`, herhangi bir değer) veya bir adım (`*/15`, her 15'te bir) kabul eder. Bu birleşim, planlanan komutun ne zaman çalışacağını tam olarak tanımlar — örneğin `0 9 * * 1-5` ifadesi "dakika 0, saat 9, herhangi bir ayın günü, herhangi bir ay, haftanın günü Pazartesi'den Cuma'ya" diye okunur — sade Türkçeyle "hafta içi 09:00".

    Cron, 1979'da Unix Sürüm 7'de ortaya çıktı ve beş alanlı dilbilgisi, kırk yılı aşkın süredir esasen değişmeden kaldı — bu, orijinal söz diziminin ne kadar iyi tasarlandığının bir kanıtıdır. Bugün cron ifadeleri Unix crontab dosyasının çok ötesinde kullanılır: Kubernetes CronJob'ları, GitHub Actions iş akışları, AWS EventBridge kuralları, GitLab CI planlı pipeline'ları, Cloudflare Workers Cron Triggers ve her buluttaki sunucusuz platformlar aynı beş alanlı dilbilgisini kabul eder. Cron'u bir kez öğrenmek, her modern altyapı bağlamında iş zamanlamayı bilmek demektir.

    POSIX standardı beş operatör tanımlar: `*` (herhangi bir değer), `,` (değer listesi), `-` (aralık), `/` (adım) ve aylar (JAN-DEC) ile haftanın günleri (SUN-SAT) için adlandırılmış belirteçler. Çoğu uygulama ayrıca beş yaygın kısayolu açar: `@yearly` (`0 0 1 1 *`), `@monthly` (`0 0 1 * *`), `@weekly` (`0 0 * * 0`), `@daily` (`0 0 * * *`) ve `@hourly` (`0 * * * *`). Quartz zamanlayıcısı (bir Java kütüphanesi) bunu isteğe bağlı bir saniye alanı ve ek operatörlerle (`?`, `L`, `W`, `#`) genişletir — Java/Spring'de çalışıyorsanız kullanışlıdır ama standart cron'a taşınabilir değildir. Bu araç POSIX beş alanlı standardını izler; çünkü baskın çeşittir ve Linux sunucunuzun, GitHub Actions runner'ınızın ve Kubernetes kümenizin gerçekte anlayacağı olandır.

    POSIX cron'un bir tuhaflığı özel dikkat hak eder: hem ayın günü hem de haftanın günü kısıtlandığında (hiçbiri `*` değilse) zamanlama HERHANGİ BİRİ eşleştiğinde çalışır — VEYA semantiği, VE değil. Yani `0 0 1 * 5` her ayın 1'inde VE her cuma çalışır; yalnızca ayın 1'ine denk gelen cumalarda değil. Bu, en yaygın cron sürprizidir; bu araçtaki sonraki çalışma önizlemesi, zamanlamanın tetikleneceği gerçek tarih-saat değerlerini göstererek durumu açıkça ortaya koyar. Dağıtımdan önce doğrulayın.

    Tüm çözümleme ve sonraki çalışma hesaplaması, JavaScript kullanılarak tamamen tarayıcınızda gerçekleşir — hiçbir ifade, zamanlama veya başka bir veri asla bir sunucuya gönderilmez. Bu araç, herhangi bir standart POSIX cron ifadesini anında sade Türkçe açıklamayla ve beş çalıştırmalık önizlemeyle çözümler; tam gizlilikle.

    Cron ifadeleri, diğer geliştirici araçlarıyla yakından ilişkilidir. Cron işleri genellikle beklenen çalıştırma sürelerine karşı Unix zaman damgalarını denetleyerek hata ayıklanır; karmaşık zamanlamalar ise sıklıkla JSON yapılandırması olarak belgelenir ve bu yapılandırma JSON biçimlendiricimizle doğrulanabilir. VEYA semantiğini, saat dilimi tuzaklarını ve Linux, Kubernetes ve GitHub Actions'ta yaygın cron çeşitlerini örneklerle ele alan ayrıntılı bir rehber için cron zamanlama referansımızı okuyun.

    # 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)

    Temel Özellikler

    Canlı POSIX 5 Alanlı Çözücü

    POSIX cron'u izleyen katı bir çözücü: dakika (0-59), saat (0-23), ayın günü (1-31), ay (1-12 veya JAN-DEC), haftanın günü (0-6 veya SUN-SAT; 7 de Pazar'ı kabul eder). Tüm standart operatörler (`*` `,` `-` `/`) ve makrolar (`@yearly` `@monthly` `@weekly` `@daily` `@hourly`) desteklenir.

    Sonraki 5 Çalıştırma Önizlemesi

    Mevcut yerel saatinize göre sonraki beş planlı çalıştırma zamanını hesaplar. Yerel ile UTC arasında tek tıkla geçiş yapın — farklı bir bölgedeki bir sunucuya crontab dağıtmadan önce saat dilimi sürprizlerini yakalamanın en güvenilir yolu.

    Sade Türkçe Açıklama

    Her geçerli ifade okunabilir bir açıklama kazanır: "Her 15 dakikada bir", "Hafta içi 09:00", "Ocak ve Temmuz'da ayın 1. gününde 02:30'da". Kod incelemesini ve ekip devrini zahmetsiz kılar — `*/5 9-17 * * 1-5` ifadesinin gerçekte ne yaptığını artık tahmin etmeniz gerekmez.

    Alan Düzeyinde Hata Mesajları

    Geçersiz ifadeler, sorunlu alanın vurgulandığı ve belirli bir hatayla anında kırmızı geri bildirim alır: "Hata: dakika alanında değer aralık dışında [0, 59]: \"60\"". Üç gün sonra raporun çalışmadığı keşfedilen sessiz crontab başarısızlıkları artık yok.

    Yaygın Zamanlamalar için Hazır Şablon Çipleri

    On bir tek tıklamalık hazır şablon, gerçekte kullanacağınız zamanlamaları kapsar: her dakika, her 5/15 dakikada bir, her saat, her gün gece yarısı veya 09:00, hafta içi 09:00, haftalık Pazar/Pazartesi, her ayın 1'inde ve yıllık. Dokunun, ince ayar yapın, dağıtın.

    Alan Başına Oluşturucu Girişleri

    Beş alanlı sırayı ezberlemeyin — Dakika, Saat, Ayın günü, Ay, Haftanın günü etiketli beş küçük giriş, bir değeri düşürmeden veya yanlış sıralamadan bir konumu düzenlemenize olanak tanır. Üstteki tam ifade otomatik olarak yeniden oluşturulur.

    POSIX VEYA Semantiği Doğru Yapıldı

    Hem ayın günü hem haftanın günü kısıtlandığında VEYA kuralı devreye girer — `0 0 1 * 5` her ayın 1'inde VE her cuma çalışır. Sonraki çalışma önizlemesi, dağıtımdan önce bunu görünür kılar; artık hafta sonu sürpriz çağrı yok.

    %100 Tarayıcı Tabanlı Gizlilik

    Genellikle altyapı zamanlamasını ve dahili zamanlama desenlerini açığa çıkaran cron ifadeleriniz tarayıcınızdan asla ayrılmaz. Hiçbir sunucuya veri gönderilmez, kayıt tutulmaz, analitik yoktur. Bunu tarayıcınızın Network sekmesinde doğrulayabilirsiniz. Üretim zamanlamaları ve dahili sistemler için güvenlidir.

    Quartz Farkındalıklı Hata Mesajları

    `?` `L` `W` veya `#` içeren bir Quartz ifadesi yapıştırırsanız çözücü "Quartz operatörleri desteklenmiyor — POSIX söz dizimini kullanın" diye açıklar; böylece sessiz bir başarısızlığı ayıklamak yerine cron için yeniden yazmanız gerektiğini bilirsiniz. Quartz zamanlamaları Linux cron üzerinde çalışmaz.

    Cron Çeşitleri ve Zamanlayıcılar

    Vixie cron (Linux varsayılanı)

    5 alanlı POSIX

    Çoğu Linux dağıtımında varsayılan. Açık saat dilimi için `CRON_TZ=` uzantısıyla katı POSIX. Ayın günü / haftanın günü VEYA semantiği geçerlidir. Bu aracın birincil hedefi.

    BSD cron

    5 alanlı POSIX

    macOS ve BSD ailesinde varsayılan. POSIX uyumlu; vixie cron'dan küçük uygulama farklılıkları içerir; çoğu ifade aynı şekilde çalışır.

    systemd zamanlayıcıları (OnCalendar)

    takvim spesifikasyonu, cron değil

    systemd tabanlı Linux'ta cron'a alternatif. `OnCalendar: 2026-*-* 09:00:00` söz dizimini kullanır — tekrarlamayan zamanlamalar için daha okunabilir ama cron ifadeleriyle birlikte çalışamaz.

    Quartz Scheduler (Java/Spring)

    6 veya 7 alan

    Saniye (zorunlu) ve yıl (isteğe bağlı) alanlarını, ayrıca `?`, `L`, `W`, `#` operatörlerini ekler. Java uygulamaları için kullanışlıdır ancak Linux cron'a taşınabilir değildir.

    AWS EventBridge

    `?` ile 6 alanlı Quartz tarzı

    Yalnızca biri kısıtlandığında haftanın gününün veya ayın gününün `*` yerine `?` olmasını gerektirir (Quartz geleneği). İfadeler doğrudan Linux cron'a taşınmaz.

    Kubernetes CronJob

    5 alanlı POSIX + timeZone alanı

    POSIX 5 alanlı zamanlama artı `spec.timeZone` alanı (1.27+). Kubelet'in host saat dilimine güvenmekten daha temizdir. İfadeler doğrudan Linux cron'dan taşınır.

    GitHub Actions

    5 alanlı POSIX

    Her zaman UTC'de çalışır. En iyi çaba zamanlaması — yüksek yük altında atlanabilir. 15 dakikadan kısa aralıklardan kaçının. İfadeler doğrudan Linux cron'dan taşınır.

    Cron İfadesi Örnekleri

    Her 15 Dakikada Bir

    */15 * * * *

    Adım operatörü: dakika alanındaki `*/15`, "dakika 0'dan başlayarak her 15 dakikada bir" anlamına gelir — yani çalıştırmalar her gün, her saatin :00, :15, :30, :45 dakikalarında olur. API yoklama, önbellek yenileme ve kalp atışı denetimleri için en yaygın aralık.

    Hafta İçi 09:00

    0 9 * * 1-5

    Haftanın günü alanındaki `1-5` aralığı Pazartesi'den Cuma'ya kadar demektir (1=Pzt, 5=Cum). Tam olarak 09:00'da çalışır — mesai saati raporları, gecelik veriye bağımlı toplu işler ve günlük standup hatırlatmaları için kullanışlıdır.

    Ayın 1'inde Gece Yarısı

    0 0 1 * *

    Ayın günü `1`, diğer alt alanlar sıfır. Aylık faturalama, log döndürme ve dönem sonu mutabakatı için yaygın. Ayın günü ve haftanın günü yalnızca her ikisi de `*` değilse kısıtlanmış sayılır — burada haftanın günü `*` olduğu için yalnızca ayın günü önemlidir.

    Hafta İçi 09:00-17:00 Arası Her 5 Dakikada Bir

    */5 9-17 * * 1-5

    Adımı (`*/5`) farklı alanlarda aralıkla (`9-17`) birleştirir. Yalnızca mesai saatinde izleme veya kuyruk boşaltma için kullanışlıdır. Toplam: saatte 12 çalıştırma × 9 saat × 5 gün = iş haftası başına 540 çalıştırma.

    Üç Aylık: Oca, Nis, Tem, Eki'nin 1'inde Gece Yarısı

    0 0 1 JAN,APR,JUL,OCT *

    Virgülle ayrılmış listede ay adları. Mali kapanış, kod-dondurma incelemeleri veya uyumluluk denetimleri gibi üç aylık zamanlamalar. Ad ve sayıları karıştırabilirsiniz (`1,APR,7,10` aynı şekilde çözümlenir), ancak okunabilirlik için tek bir biçime sadık kalın.

    POSIX VEYA Tuzağı: Ayın 1'i VEYA Her Cuma

    0 0 1 * 5

    Ayın günü (`1`) VE haftanın günü (`5`) birlikte kısıtlandığında, POSIX cron HERHANGİ BİRİ eşleşirse işi çalıştırır. Yani bu ifade her ayın 1'inde VE her cuma tetiklenir — yalnızca ayın 1'ine denk gelen cumalarda değil. Bu, en yaygın cron sürprizidir; sonraki çalışma önizlemesi durumu açıkça gösterir.

    Her Gün 02:30 (Düşük Trafik Penceresi)

    30 2 * * *

    Hem saat hem de dakika için belirli değerler, diğer yerlerde jokerler. 02:00-04:00 UTC penceresi, gecelik toplu işler için fiili gelenektir; çünkü hiçbir büyük iş bölgesinin çalışma saatleriyle çakışmaz. Çalıştırmanın beklediğiniz yere düştüğünü doğrulamak için UTC saat dilimi düğmesiyle eşleştirin.

    Makro Eşdeğeri: @daily

    @daily

    `@daily` kısayolu (aynı zamanda `@midnight`), `0 0 * * *` ifadesine açılır — her gün gece yarısı. Diğer makrolar: `@yearly` = `0 0 1 1 *`, `@monthly` = `0 0 1 * *`, `@weekly` = `0 0 * * 0`, `@hourly` = `0 * * * *`. Makrolar özlüdür ancak beş alanlı biçim, zamanlayıcılar arasında daha taşınabilirdir (örn. bazıları makroları destekler, bazıları desteklemez).

    Cron İfadesi Nasıl Oluşturulur

    1. 1

      Bir cron ifadesi yazın veya yapıştırın

      Yukarıdaki giriş alanına beş alanlı bir cron ifadesi girin (örn. `*/15 * * * *`). Araç yazdıkça çözümler ve doğrular — geçerli için yeşil onay, geçersiz için alan adıyla kırmızı hata. `@daily`, `@hourly` vb. makrolar da kabul edilir.

    2. 2

      Veya beş alanlı girişleri ayarlayın

      Alan sırasını ezberlemeyin — etiketli girişleri kullanarak Dakika, Saat, Ayın günü, Ay veya Haftanın günü değerlerini ayrı ayrı düzenleyin. Üstteki tam ifade otomatik olarak güncellenir. Joker için `*`, adımlar için `*/N`, aralıklar için `a-b` ve listeler için `1,3,5` kullanın.

    3. 3

      Başlamak için bir hazır şablon seçin

      Yaygın bir zamanlama yüklemek için herhangi bir hazır şablon çipine (Her 15 dakikada bir, Hafta içi 09:00 vb.) dokunun, ardından alanları tam ihtiyacınıza göre ince ayarlayın. On bir hazır şablon, üretimde gerçekte kullanacağınız desenleri kapsar.

    4. 4

      Sonraki çalışma önizlemesini doğrulayın

      Önümüzdeki beş çalıştırma tarih-saatine bakın — zamanlamanın istediğiniz anda tetiklendiğini doğrulamak için Yerel ile UTC arasında geçiş yapın. Bu, POSIX ayın günü / haftanın günü VEYA tuzağını üretim ortamına ulaşmadan yakalamanın en güvenilir tek yoludur.

    5. 5

      Kopyalayıp zamanlayıcınıza yapıştırın

      İfadeyi almak için Kopyala'ya tıklayın. crontab'inize, systemd zamanlayıcınıza, GitHub Actions `cron:` alanına, AWS EventBridge'e, Kubernetes CronJob `schedule` alanına veya herhangi bir cron uyumlu zamanlayıcıya yapıştırın. Hedef zamanlayıcının saat dilimini doğrulamayı unutmayın — aşağıdaki En İyi Uygulamalar bölümüne bakın.

    Yaygın Cron Hataları

    POSIX VEYA Tuzağı: Her İki Gün Alanı da Kısıtlı

    Hem ayın günü hem de haftanın günü kısıtlandığında POSIX cron, HERHANGİ BİRİ eşleşirse işi çalıştırır — ikisi birden değil. Yani `0 0 1 * 5` her ayın 1'inde VE her cuma tetiklenir; yalnızca ayın 1'ine denk gelen cumalarda değil. Tek bir koşul istediğinizde iki gün alanından birinde `*` kullanın veya VE denetimini yapan bir sarmalayıcı betik yazın.

    ✗ Yanlış
    # Hedef: "ayın ilk cumasında"
    0 0 1-7 * 5
    # Gerçekte: ayın 1-7 günlerinde VEYA her cuma çalışır — iki koşul
    ✓ Doğru
    # Gerçek VE semantiği için sarmalayıcı kullanın
    0 0 * * 5  [ $(date +\%d) -le 7 ] && /betiginiz
    # VEYA bir koşulu bırakın ve daha gevşek zamanlamayı kabul edin

    Geliştirme ve Üretim Arasında Saat Dilimi Sapması

    Linux sunucusundaki cron zamanlamaları, yazarın yerel saat diliminin değil sistem saat diliminin kullanır. UTC'ye ayarlanmış bir sunucudaki 09:00 cron, ABD Doğu saatiyle 04:00'te tetiklenir. Zamanlamaları her zaman hedef sunucunun saat dilimine karşı — tercihen UTC'ye karşı — tasarlayın ve saat dilimini crontab'in başında `CRON_TZ=...` ile açıkça sabitleyin.

    ✗ Yanlış
    # ABD Doğu'da yazıldı, UTC sunucusuna dağıtıldı
    0 9 * * *  /raporunuz.sh
    # UTC 09:00 = ABD Doğu 04:00'te tetiklenir — geliştiricinin kastettiği değil
    ✓ Doğru
    # Saat dilimini sabitleyin veya UTC'de açıkça yazın
    CRON_TZ=America/New_York
    0 9 * * *  /raporunuz.sh

    Adım Operatörü Karışıklığı: '*/15' ve '15'

    Dakika için `*/15`, "0'dan başlayarak her 15 dakikada bir" anlamına gelir (yani 0, 15, 30, 45). Yalnızca `15` ise "yalnızca dakika 15'te" anlamına gelir — saatte bir çalıştırma. Yeni başlayanlar sıkça `15` yazarak her 15 dakikada bir çalışacağını sanır; aracın sade Türkçe açıklaması, hatayı dağıtımdan önce açık eder.

    ✗ Yanlış
    # Hedef: her 15 dakikada bir
    15 * * * *
    # Gerçekte: saatte bir kez, dakika 15'te (hedefe göre saatte 4 çalıştırma az)
    ✓ Doğru
    # Doğru
    */15 * * * *
    # Her 15 dakikada bir: her saatin 0, 15, 30, 45. dakikasında

    POSIX Zamanlayıcıda Altı Alanlı İfade

    Quartz/Spring/node-cron, ilk konumda isteğe bağlı bir saniye alanını destekler. Linux crontab, GitHub Actions, AWS EventBridge (çoğunlukla) ve Kubernetes CronJob DESTEKLEMEZ — beş alan beklerler. Altı alanlı bir ifadeyi yapıştırmak zamanlamayı sessizce bozar: saniyeleriniz dakika, dakikalarınız saat olur, vb.

    ✗ Yanlış
    # Linux crontab'a kopyalanan Quartz 6 alanlı ifade
    0 0 9 * * 1-5
    # Linux okuması: dakika=0, saat=0, ayın günü=9, ay=*, haftanın günü=1-5
    # = hafta içiyle eşleşen aylarda 9. günlerde gece yarısı — kaos
    ✓ Doğru
    # POSIX 5 alanlı, saniyeleri bırakın
    0 9 * * 1-5
    # = hafta içi 09:00

    Ay İçin Aralık Dışı Ayın Günü

    Cron, ayın gününü gerçek aya karşı doğrulamaz. `0 0 31 2 *` (Şubat 31) sorunsuz çözümlenir ancak asla eşleşmez — Şubat en fazla 29 gündür. Yeni başlayanlar çözücünün bunu yakalayacağını varsayar; yakalamaz. Bu araçtaki sonraki çalışma önizlemesi, bir ifade yapısal olarak geçerli ama mantıksal olarak imkânsız olduğunda "Planlı çalıştırma yok" gösterir.

    ✗ Yanlış
    # Şubat 30 veya 31 — asla çalışmaz
    0 0 30 2 *
    0 0 31 2 *
    # Çözümlenir ama hiçbir zamanlama tetiklenmez
    ✓ Doğru
    # Betik aracılığıyla 'Şubat'ın son hafta içi günü' desenini kullanın
    0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /betiginiz

    Quartz Söz Dizimini POSIX Sanmak

    AWS belgeleri, Spring eğitimleri ve birçok Stack Overflow yanıtı `?`, `L`, `W` veya `#` içeren Quartz cron ifadeleri gösterir. Bunlar Linux crontab'de çalışmaz. Haftanın günü konumunda `?` içeren altı alanlı bir ifadeyi kopyalarsanız Linux çözücüsü onu reddeder (ya da daha kötüsü sessizce yanlış çözümler). Bu araç Quartz operatörlerini yakalar ve farkı açıklar.

    ✗ Yanlış
    # Quartz: 'ayın son cuması' — POSIX'te geçersiz
    0 0 ? * 6L *
    ✓ Doğru
    # Son cuma için POSIX sarmalayıcı betik yaklaşımı
    0 0 25-31 * 5  /betiginiz
    # Herhangi bir ayın 25-31. günleri arasındaki cuma günü çalışır

    Yaygın Kullanım Senaryoları

    Linux Crontab İşleri
    `/etc/crontab`, `/etc/cron.d/*` veya kullanıcı başına `crontab -e` dosyaları için kayıtlar oluşturun ve doğrulayın. Kaydetmeden önce zamanlamanın, sunucunuzun yapılandırılmış saat diliminde doğru saate düştüğünü doğrulamak için sonraki çalışma önizlemesini kullanın.
    Kubernetes CronJob Zamanlamaları
    Bir Kubernetes CronJob için `spec.schedule` alanını üretin. Kubernetes 1.27+ aynı zamanda `spec.timeZone` alanını destekler — zamanlamanızı UTC'de tasarlamak için UTC düğmesini kullanın, ardından worker düğümünün yerel saatinden kaçınmak için `timeZone` değerini açıkça ayarlayın.
    GitHub Actions Planlı İş Akışları
    `on.schedule` altındaki `cron:` kaydını oluşturun. GitHub Actions her zaman UTC'de çalışır — zamanlamanızı doğrulamak için önizlemeyi UTC'ye getirin. 15 dakikadan kısa aralıklardan kaçının; GitHub'ın zamanlayıcısı yük altında kısa aralıklı işleri atlar.
    AWS EventBridge Kuralları
    Bir EventBridge planlı kuralı için cron ifadesini oluşturun. Not: AWS, haftanın günü için `?` kullanan Quartz tarzı altı alanlı söz dizimini kullanır — bu araç POSIX beş alanlı üretir; saniyeleri (`0`) önek olarak ekleyip iki gün alanından birinin `*` değerini `?` ile değiştirerek dönüştürmeniz gerekir.
    GitLab CI Planlı Pipeline'ları
    GitLab'da planlı bir CI pipeline'ı için cron ifadesini doğrulayın. GitLab, POSIX beş alanlı söz dizimi kullanır — yani bu aracın ürettiği — ve bir UI tarih seçici sunar; ancak cron biçimi, standart dışı aralıklar için size daha ince denetim sağlar.
    Cloudflare Workers Cron Triggers
    `wrangler.toml` içindeki `[triggers.crons]` kaydını oluşturun. Cloudflare, POSIX beş alanlı söz dizimi kullanır. Minimum aralık bir dakikadır; worker UTC'de çalışır. Tetikleyicinin beklenen pencere içinde tetiklendiğini doğrulamak için önizlemeyi kullanın.
    Node.js node-cron Zamanlamaları
    Hem beş alanlı POSIX'i hem de isteğe bağlı önde gelen bir saniye alanını destekleyen `node-cron` kütüphanesi için ifadeler oluşturun. Özellikle dakika altı hassasiyete ihtiyacınız yoksa beş alana sadık kalın — altı alanlı ifadeler Linux crontab'e taşınmaz.
    Kod İncelemesi ve Belgeleme
    Ne yaptığını anında görmek için bir PR'den veya runbook'tan bir cron ifadesi yapıştırın — `30 7 * * 1-5` ifadesini tahmin etmek veya başvuru kartı çıkarmak zorunda kalmazsınız. Sade Türkçe açıklama, satır içi yorumlar ve README dosyaları için de harikadır.

    Cron Söz Dizimi Referansı

    Alan Sırası: D S G A H
    Dakika (0-59), Saat (0-23), Ayın günü (1-31), Ay (1-12), Haftanın günü (0-6; 7 de = Pazar). Haftanın günü alanı hem sayısal (0-6) hem de adlandırılmış (SUN-SAT, büyük/küçük harfe duyarsız) belirteçleri kabul eder.
    Operatörler
    `*` = herhangi bir değer; `,` = liste ayırıcısı (`1,3,5`); `-` = aralık (`1-5`); `/` = adım (`*/15`, `5/10`); adlar: ay için JAN-DEC, haftanın günü için SUN-SAT (büyük/küçük harfe duyarsız).
    Makrolar (Takma Adlar)
    `@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` özel bir zamanlama dışı kayıttır (yalnızca önyüklemede çalışır) ve açıklayıcı bir hatayla reddedilir.
    POSIX Gün Semantiği (VEYA Kuralı)
    Hem ayın günü hem de haftanın günü kısıtlandığında (hiçbiri `*` değilse) zamanlama HERHANGİ BİRİ eşleştiğinde çalışır — VEYA semantiği. Yalnızca biri kısıtlandığında karar onun olur. Her ikisi de `*` olduğunda her gün eşleşir. Bu VEYA kuralı vixie cron'a, BSD cron'a ve çoğu POSIX uygulamasına uygulanır; Quartz, VE ile VEYA'yı ayırmak için `?` kullanır.
    Altı Alanlı Mod (Quartz-Lite)
    Girdiniz altı boşlukla ayrılmış belirteç içeriyorsa araç ilkini bir saniye alanı (0-59) olarak ele alır. Quartz, Spring `@Scheduled(cron=...)` ve node-cron için kullanışlıdır. Linux crontab'a veya POSIX zamanlayıcılarına TAŞINABİLİR DEĞİLDİR — onlar saniyenizi dakika olarak yorumlar ve her şeyi bir konum kaydırır.
    Adım Operatörü Sabitlemesi
    `*/N`, alanın en düşük değerine sabitlenir: dakika için `*/15` = `0,15,30,45`, "şu andan başlayarak her 15'te bir" değil. Joker olmayan bir tabanla: dakika için `5/15` = `5,20,35,50`. Alan aralığını eşit bölmeyen adım değerleri sarmalama yakınında atlama yapar — bu doğrudur, hata değildir.
    Doğrulama Sınırları
    dakika ∈ [0,59], saat ∈ [0,23], ayın günü ∈ [1,31], ay ∈ [1,12], haftanın günü ∈ [0,7]. Aralık dışı değerler alan düzeyinde bir hata üretir. Ayın günü, aya karşı doğrulanmaz (`0 0 31 2 *` sorunsuz çözümlenir, ancak Şubat'ta 31. gün olmadığı için asla eşleşmez — sonraki çalışma önizlemesi "Planlı çalıştırma yok" gösterir).
    Quartz Operatörleri Reddedildi
    POSIX cron, Quartz'ın `?` (belirli değer yok), `L` (last), `W` (en yakın hafta içi gün) veya `#` (n'inci hafta günü) operatörlerini desteklemez. Bu araç bunları sessizce geçersiz POSIX olarak çözümlemek yerine açık bir "Quartz operatörleri desteklenmiyor" mesajıyla reddeder. Quartz zamanlamaları için Quartz farkındalıklı bir araç veya Spring zamanlayıcısı kullanın.
    Sonraki Çalışma Aramasında Yıl Sınırı
    Sonraki çalışma hesaplaması 4 yıla kadar ileri arar; bundan daha seyrek eşleşen ifadeler (örn. "29 Şubat" desenleri) "Önümüzdeki 4 yıl içinde planlı çalıştırma yok" gösterir. Bu, imkânsız desenlerde sınırsız yinelemeden kaçınmak için tasarlanmıştır.

    Cron Zamanlamaları için En İyi Uygulamalar

    Sunucularda UTC Kullanın, Görüntülerken Dönüştürün
    Sunucularınızı UTC'ye ayarlayın (`/etc/timezone` veya `TZ=UTC`) ve tüm cron ifadelerini UTC'de yazın. Yalnızca panolarınızda ve raporlarınızda görüntüleme sırasında yerel saate dönüştürün. Bu, yaz saati geçişleri sırasında en sert şekilde vuran — yerel saatli zamanlamaların sessizce iki kez tetiklendiği veya bir çalıştırmayı atladığı — saat dilimi hatalarının tüm bir kategorisini ortadan kaldırır. Zamanlamanızı baştan UTC'de tasarlamak için bu araçtaki UTC düğmesini kullanın.
    POSIX Ayın Günü/Haftanın Günü VEYA Tuzağından Kaçının
    VEYA semantiğini istemiyorsanız hem ayın gününü HEM de haftanın gününü asla kısıtlamayın. "Ocak'taki her Pazartesi" istiyorsanız `0 0 * 1 1` yazın (ayın günü `*`); "her ayın 1'i" istiyorsanız `0 0 1 * *` yazın (haftanın günü `*`). POSIX VEYA kuralı, `0 0 1 * 1` ifadesinin ayın 1'inde VE her Pazartesi çalışacağı anlamına gelir — neredeyse kesinlikle istediğiniz bu değildir. Dağıtımdan önce kontrol ederseniz sonraki çalışma önizlemesi bunu yakalar.
    Zamanlamanın Saat Dilimini Açıkça Sabitleyin
    Modern zamanlayıcılar, saat dilimini zamanlama tanımında sabitlemeyi destekler: crontab'in başında `CRON_TZ=America/New_York` (vixie cron 3.0+), Kubernetes CronJob 1.27+ için `spec.timeZone: "America/New_York"`, AWS EventBridge Scheduler için `ScheduleExpressionTimezone` ile zamanlama ifadesi. Sunucunun varsayılanına güvenmek yerine saat dilimini açıkça sabitleyin — altyapı geçişleri sırasında sunucu saat dilimleri uyarı olmadan değişebilir.
    Yükü Dakikalara Yayın, :00'da Toplamayın
    Kritik olmayan işler için `0 * * * *` ifadesinden kaçının (her saat dakika 0'da) — ölçekte tam olarak :00'da çok şey planlamak yük artışları yaratır. Her iş için rastgele bir dakika ofseti seçin (`23 * * * *`, `41 * * * *`) ve yükü yayın. Aynı durum günlük işler için de geçerlidir: 3:00'te birçok iş birleştiğinde `30 3 * * *`, veritabanınıza `0 3 * * *` ifadesinden daha dosttur.
    İşleri İdempotent Yapın
    Cron'da yerleşik yeniden deneme, örtüşme önleme veya atlanan çalıştırma kurtarma yoktur. İşinizin birden çok kez çalıştırılması güvenli (idempotent) ve kendini kontrol edici olmalıdır. "09:00'da rapor gönder" yerine "bugünün raporu henüz gönderilmediyse gönder" olarak tasarlayın — bu, kesintiden, kazara çift zamanlamadan ve eşzamanlı çalıştırmadan sonra kendiliğinden iyileşir. İdempotency, zamanlayıcının değil işin bir özelliğidir ve tek en önemli güvenilirlik uygulamasıdır.
    Kritik Zamanlamalar İçin Kalp Atışı Ekleyin
    Cron'un sessiz başarısızlık modu en büyük zayıflığıdır — zamanlama tetiklenmezse hiçbir şey size haber vermez. Kritik işler için her çalıştırmanın sonunda işin bir kalp atışı hizmetine (Healthchecks.io, Cronitor, Dead Man's Snitch) ping göndermesini sağlayın; beklenen ping ulaşmadığında hizmet size uyarı verir. Bu hem işin başarısız olmasını hem de zamanlamanın yanlış tetiklenmesini yakalar. Ücretsiz katman çoğu bireysel ve küçük ekip ihtiyacını karşılar.
    Dağıtmadan Önce Sonraki Çalışma Önizlemesiyle Doğrulayın
    Yeni bir cron zamanlamasını dağıtmadan önce bu aracın önizlemesindeki beş yaklaşan çalıştırma tarih-saatine bakın. Yerel ile UTC arasında geçiş yapın. Zamanlamanın istediğiniz anda düştüğünü doğrulayın — beş dakika erken değil, yanlış günde değil, önemsediğiniz hafta sonunu atlamadan. Önizleme, mümkün olan en ucuz üretim testidir.

    Sıkça Sorulan Sorular

    Bu araç ne işe yarar?
    Cron ifadelerini tarayıcınızda çözümler, doğrular ve açıklar; sonraki beş planlı çalıştırmanın saat diliminizdeki veya UTC'deki canlı önizlemesini sunar. Herhangi bir standart POSIX beş alanlı cron ifadesini yazın — veya söz dizimini ezberlemeden bir tane oluşturmak için hazır şablonları ve alan başına girişleri kullanın — araç sade Türkçe bir açıklama ("Her 15 dakikada bir", "Hafta içi 09:00" vb.) ve işin tetikleneceği gerçek tarih-saat değerlerini üretir. Hatalı ifadeler, alan düzeyinde hata mesajıyla anında yakalanır; böylece bozuk bir zamanlama için boşa dağıtım yapmazsınız. Tüm araç %100 istemci tarafında çalışır: hiçbir şey yüklenmez, kaydedilmez veya saklanmaz — üretim crontab'leri ve hassas zamanlama desenleri içeren dahili zamanlamalar için güvenlidir.
    Cron ifadesi nedir?
    Cron ifadesi, tekrarlayan bir zamanlamayı tanımlayan beş alanlı bir karakter dizisidir. Alanlar şunlardır: dakika (0-59), saat (0-23), ayın günü (1-31), ay (1-12) ve haftanın günü (0-6; burada 0 ve 7 her ikisi de Pazar anlamına gelir). Her alan; bir değer, bir liste (`1,3,5`), bir aralık (`1-5`), bir joker (`*` = herhangi biri) veya bir adım (`*/15` = her 15'te bir) kabul eder. Beş alanın tamamının birleşimi, planlanan komutun ne zaman çalışacağını tam olarak tanımlar. Cron, Unix V7'de (1979) ortaya çıktı ve Linux/Unix üzerinde zamana dayalı iş zamanlamasının, konteyner düzenlemesinin (Kubernetes CronJob'ları), CI/CD'nin (GitHub Actions, GitLab CI) ve sunucusuz platformların (AWS EventBridge, Cloudflare Workers Cron Triggers) fiili dili olmayı sürdürür. Onlarca yıl boyunca pek çok alternatif önerilse de hiçbiri cron'un kısa ve anlamlı beş alanlı dilbilgisinin yerini alamadı.
    Verilerim herhangi bir yere yükleniyor mu?
    Hayır. Tüm çözümleme, doğrulama ve sonraki çalışma hesaplaması, JavaScript kullanılarak %100 tarayıcınızda istemci tarafında gerçekleşir. İfadeleriniz asla iletilmez, hiçbir sunucuda saklanmaz, kaydedilmez ve analiz edilmez. Bu, aracı üretim crontab'leri, altyapı zamanlamasını açığa çıkaran dahili zamanlama desenleri ve hassas zamanlamalar için güvenli kılar. Bunu tarayıcınızın Network sekmesinde doğrulayabilirsiniz — bir cron ifadesi yazmak sıfır ağ isteği tetikler. Araç, girdi verisi için çerez kullanmaz ve yazdıklarınızı yakalayabilecek üçüncü taraf analitiklerden yoksundur.
    POSIX cron ile Quartz arasındaki fark nedir?
    POSIX cron; Unix/Linux crontab, systemd zamanlayıcıları, GitHub Actions, GitLab CI, AWS EventBridge, Kubernetes CronJob ve çoğu zamanlayıcı tarafından kullanılan beş alanlı standarttır. Quartz ise bir saniye alanı (toplam altı veya yedi alan) ve ek operatörler ekleyen bir Java zamanlama kütüphanesidir: `?` (belirli değer yok, ayın günü ve haftanın günü çakıştığında kullanılır), `L` (last — ayın son günü, son cuma vb.), `W` (en yakın hafta içi gün) ve `#` (ayın n'inci hafta günü, örn. `2#1` = ilk salı). Bu araç POSIX cron'u uygular; çünkü çok daha yaygın kullanılır. Quartz operatörleri, açık bir "Quartz operatörleri desteklenmiyor" mesajıyla söz dizimi hatası olarak bildirilir. Quartz'a ihtiyacınız varsa hedefiniz Quartz Scheduler ve Spring'in `@Scheduled` gibi popüler Java zamanlayıcılarıdır — ancak zamanlama tanımları doğrudan Linux cron'a taşınmaz.
    '0 0 1 * 5' neden her cuma VE ayın 1'inde çalışıyor?
    Bu, POSIX cron'un ayın günü / haftanın günü VEYA semantiğidir ve en yaygın cron sürprizidir. Kural şudur: her iki alan da kısıtlandığında (hiçbiri `*` değilse) cron, HERHANGİ BİRİ eşleşirse işi çalıştırır — her ikisi birden değil. Yani `0 0 1 * 5` (ayın günü=1, haftanın günü=5) her ayın 1'inde VE her cuma tetiklenir; yalnızca ayın 1'ine denk gelen cumalarda değil. Yalnızca ikincisini (VE semantiği — ayın 1'ine denk gelen cuma) istediyseniz bunu standart cron'da ifade edemezsiniz; her cuma VEYA ayın 1'inde çalışan ve gerçek tarihe göre erken çıkan bir betik yazmanız gerekir. Vixie cron (GNU/Linux varsayılanı), BSD cron ve AWS EventBridge bu VEYA kuralını izler. Bu araçtaki sonraki çalışma önizlemesi gerçek zamanlamayı açıkça gösterir — şüpheli ifadeleri yapıştırın ve dağıtımdan önce doğrulayın.
    Her 30 saniyede bir iş nasıl çalıştırılır?
    Standart POSIX cron ile çalıştıramazsınız. Cron'un minimum çözünürlüğü bir dakikadır — en küçük alan dakikadır (0-59). Dakika altı zamanlamalar için seçenekleriniz şunlardır: (1) `* * * * *` ile iki iş çalıştırın ve birinin başına `sleep 30 &&` ekleyin — kaba bir çözüm ama vixie cron için işe yarar. (2) Quartz, özel denetleyiciye sahip Kubernetes CronJob veya `OnCalendar: *-*-* *:*:00/30` ile systemd zamanlayıcıları gibi saniye desteği olan bir zamanlayıcı kullanın. (3) Yinelemeler arasında 30 saniye uyuyan uzun ömürlü bir daemon çalıştırın — çoğu izleme ihtiyacı için doğru yanıt budur. (4) Gerçekten gerçek zamanlı yanıta ihtiyacınız varsa olay güdümlü bir tetikleyiciye (webhook, mesaj kuyruğu) geçin. 30 saniyelik cron deseni neredeyse her zaman cron'un yanlış soyutlama olduğunun bir işaretidir.
    Cron hangi saat dilimini kullanır?
    Bir Linux sunucusunda vixie cron, sistemin saat dilimini kullanır — genellikle `/etc/timezone` veya `TZ` ortam değişkeniyle ayarlanır. Bu sık bir hata kaynağıdır: ABD Doğu sunucusunda 09:00 cron, UTC 14:00'te tetiklenir; ancak UTC'ye ayarlanmış bir sunucuda UTC 09:00'da (yani Doğu saatiyle 04:00) tetiklenir. Çözüm, ya sunucularınızı her zaman UTC'ye ayarlayıp tüm cron ifadelerini UTC'de yazmaktır ya da saat dilimini açıkça sabitlemek için crontab'in başına `CRON_TZ=America/New_York` değişkenini koymaktır (vixie cron 3.0+ destekler). Yönetilen zamanlayıcılar değişiklik gösterir: GitHub Actions her zaman UTC'de çalışır, AWS EventBridge zamanlama tanımında saat dilimini destekler, Kubernetes CronJob 1.27+ sürümünde `spec.timeZone` alanını ekledi. Bu aracın UTC/Yerel düğmesi, zamanlamayı her iki saat diliminde önizlemenize olanak tanır — çalıştırmanın istediğiniz yere düştüğünü doğrulamak için aralarında geçiş yapın.
    '*/15' gerçekte neye açılır?
    `*/N` adım operatörü, "alanın en düşük geçerli değerinden başlayarak her N'de bir" anlamına gelir. Dakika için (aralık 0-59) `*/15`, `0,15,30,45` ifadesine açılır — saat başına dört çalıştırma, çeyrek saatlerde. Adım, "şu andan itibaren her 15 dakikada bir" DEĞİLDİR; alanın başlangıç değerine sabitlenmiştir. Diğer alanlar için aynı mantık: saat için `*/2` = `0,2,4,...,22` (12 çalıştırma); ayın günü için `*/3` = `1,4,7,...,31` (11 çalıştırma). Joker olmayan adım tabanları için (örn. `5/15`), açılım tabandan başlar: dakika için `5/15` = `5,20,35,50`. Aralığı tam bölmeyen adım değerleri sarmalama yakınında atlama yapar — bu doğru cron davranışıdır, hata değildir. Sonraki çalışma önizlemesi gerçek zamanlamayı açıkça gösterir.
    Saniyelerle altı alanlı bir ifade kullanabilir miyim?
    Önde gelen saniye alanı (aralık 0-59) bulunan altı alanlı ifadeler bir Quartz/Spring/Cron4j uzantısıdır, POSIX değildir. Bu araç, girdi tam olarak altı boşlukla ayrılmış belirteç içerdiğinde altı alanlı ifadeleri kabul eder — Quartz'ı, Spring `@Scheduled(cron=...)` veya `node-cron` gibi saniye destekleyen Node.js kütüphanelerini hedefliyorsanız kullanışlıdır. Standart POSIX zamanlayıcılar (Linux crontab, GitHub Actions, AWS EventBridge, Kubernetes CronJob) için beş alana sadık kalın — önde gelen bir saniye alanı eklemek zamanlamayı sessizce bozar (zamanlayıcı dakikanızı saniye, saatinizi dakika vb. olarak yorumlar ve her şeyi bir konum kaydırır). Şüpheniz varsa hedef zamanlayıcınızın belgelerine bakın; "saniyeli altı alan destekleniyor" açıkça yazmıyorsa beş alan kullanın.
    Cron'un ifade edebileceği en uzun aralık nedir?
    Harici durum olmadan cron, `0 0 D M *` ile (örn. `0 0 1 1 *` = her 1 Ocak gece yarısı) yılda bir kez güvenilir biçimde ifade edebilir. "Her iki yılda bir" veya daha uzun aralıklar için cron tek başına yeterli değildir — betiğinizin başına harici bir tarih denetimi eklemeniz gerekir (örn. çift sayılı yıllarda çalıştırmak için `[ $(($(date +%Y) % 2)) -eq 0 ] && /komut-girin`). "Her 90 günde bir" veya diğer hizalanmamış çoklu gün aralıkları için de cron yetersiz kalır: yerel modulo-gün operatörü yoktur; bu nedenle yılın gününü bir referans tarihe karşı denetleyen bir sarmalayıcı yazmanız gerekir. Zamanlama ihtiyaçlarınız bu kadar karmaşıksa gerçek bir iş akışı zamanlayıcısını (Airflow, Temporal, AWS Step Functions) düşünün — cron'un dilbilgisi kasıtlı olarak basittir ve düzenli haftalık/aylık desenlerin ötesinde her şey için bozulur.
    Kesintiden sonra atlanan çalıştırmaları nasıl ele alırım?
    Standart cron'da kurtarma yoktur — sistem planlanan zamanda kapalıysa çalıştırma yalnızca atlanır. "Bunu kaçırdık" diye bir log yoktur. Kritik işler için üç seçeneğiniz vardır: (1) Önyüklemeden sonra atlanan işleri yakalayan, dizüstü bilgisayarlar ve aralıklı sistemler için uygun olan `anacron` (veya `Persistent=true` ile `systemd-cron`) kullanın. (2) Yerleşik yeniden denemesi olan bir zamanlayıcıya geçin: Kubernetes CronJob'ları `startingDeadlineSeconds` (gecikme süre içindeyse çalıştır) ve `concurrencyPolicy` (örtüşen çalıştırmaları önle) özelliklerine sahiptir; AWS EventBridge yeniden deneme politikalarını destekler. (3) İşin kendisine idempotency yerleştirin: "09:00'da raporu gönder" yerine "bugünün raporu üretildi mi?" sorgulayan ve üretilmediyse üreten bir iş tasarlayın — bu, herhangi bir kesinti uzunluğundan sonra kendiliğinden iyileşir. Üçüncü seçenek en sağlam olanıdır ve herhangi bir zamanlayıcıyla çalışır.
    GitHub Actions cron'um neden zamanında çalışmıyor?
    GitHub Actions zamanlamaları en iyi çaba ilkesine göredir: GitHub altyapısı üzerinde yüksek yük altında birkaç dakika geç tetiklenebilirler ve çok yüksek yük sırasında tamamen atlanabilirler (özellikle her beş dakika gibi kısa aralıklarda). Aynı çekince çoğu yönetilen zamanlayıcı için geçerlidir — ölçek ve güvenilirlik karşılığında tam zamanlamayı feda ederler. Pratik sonuçlar: (1) Belirli bir saniyede çalışması gerekenleri planlamayın; cron, "günde aşağı yukarı bu saatte" içindir. (2) Kısa aralıklar için planlı bir iş yerine uzun ömürlü bir worker'ı tercih edin. (3) Tam zamanlı finansal veya uyumluluk kesintileri için kontrolünüzdeki bir sunucuda özel bir cron daemon'u veya Standart zamanlama ile AWS EventBridge Scheduler gibi daha katı bir zamanlayıcı kullanın. (4) Özellikle GitHub Actions: 15 dakikadan kısa aralıklardan kaçının; zamanlayıcı bunları yük altında genellikle atlar.