Cron Job Alternatifleri Hangi Zamanlayıcıyı Seçmelisiniz?

Geleneksel UNIX cron servisi yarım asra yakın süredir periyodik arka plan işlerinin vazgeçilmez aracı olmuştur. Tek bir satır ile gece yarısı yedek alma veya saat başı rapor üretme pratikliği sağlasa da, modern bulut mimarileri, mikroservisler ve dağıtık sistemler geliştikçe cron altyapısının eksiklikleri belirginleşmiştir. Kaçırılan çalışmaların telafi edilememesi, bağımlılık yönetiminin bulunmaması ve merkezi gözlemlenebilirlik eksikliği geliştiricileri alternatif çözümler aramaya yöneltir.

Bu rehberde, geleneksel cron yerine değerlendirebileceğiniz sistem düzeyindeki modern zamanlayıcıları, masaüstü veya kesintili çalışan sunucular için özel araçları, uygulama içi dağıtık kuyrukları ve bulut tabanlı webhook zamanlayıcılarını derinlemesine inceliyoruz. Temel kavramları tazelemek isterseniz öncelikle cron job nedir rehberimize göz atabilirsiniz.

Neden Cron Alternatifi Aranır? (Geleneksel Cron'un Sınırları)

Klasik crontab servisi yerel sunucu ortamında çalışır ve her dakikada bir /etc/crontab veya kullanıcı tablolarını tarar. Ancak üretim sistemlerinde karşılaşılan pek çok operasyonel gereksinim cron mimarisinin sınırlarını aşar:

• Kaçırılan Çalışmaları Telafi Edememe: Sunucunuz gece saat 03:00'te bakım veya elektrik kesintisi nedeniyle kapalıysa, o saatte çalışması planlanan veritabanı yedeği sessizce atlanır. Sunucu 03:30'da yeniden açıldığında cron geriye dönük telafi çalıştırması yapmaz.
• Servis Bağımlılığı ve Sıralama Yokluğu: Cron, görevi çalıştırmadan önce PostgreSQL veya Redis servisinin çalışır durumda olup olmadığını denetlemez. Sunucu açılışında veritabanı hazır olmadan tetiklenen betikler kaçınılmaz olarak çöker.
• Yetersiz Loglama ve Hata Takibi: Standart cron yalnızca yerel sistem günlüğüne bir komutun başlatıldığını yazar. Çıktıyı incelemek için ya e-posta yönlendirmesi (sendmail) kurmanız ya da komut sonuna >> /var/log/cron.log 2>&1 eklemeniz gerekir. Merkezi hata eşiği, yanıt süresi ve otomatik uyarı mekanizmaları bulunmaz.
• Kaynak İzolasyonu Eksikliği: Cron tarafından başlatılan ağır bir Python veya PHP betiği sunucudaki tüm CPU ve RAM kaynaklarını tüketerek ana web uygulamasını kilitleyebilir. Linux cgroups ile entegre bir kaynak limiti sunmaz.
• Dağıtık Sunucu Çakışmaları: Yük dengeleyici arkasında çalışan birden fazla web sunucunuz varsa, her sunucudaki crontab aynı görevi bağımsız olarak çalıştırır. Bu durum mükerrer fatura kesilmesine, çift e-posta gönderilmesine veya veritabanı kilitlenmelerine yol açar.

Derinlemesine Karşılaştırma Tablosu: Cron vs Systemd Timers vs Anacron vs Webhook Cron

Kısa yanıt: Tek bir Linux sunucusunda kalıcıyorsanız systemd timer, makine sık kapanıyorsa anacron, görev uygulamanın koduna ve veritabanına dokunuyorsa kuyruk tabanlı bir zamanlayıcı, tetiklenecek şey bir HTTPS adresiyse web cron en dengeli seçimdir.

Aşağıdaki karşılaştırma tablosu, popüler zamanlama yaklaşımlarını mimari yeteneklerine, hassasiyetlerine ve operasyonel maliyetlerine göre özetlemektedir:

Alternatif 1: Linux Systemd Timers (Modern Sistem Standardı)

Ubuntu, Debian, CentOS, RHEL ve Arch Linux dahil olmak üzere pek çok güncel Linux dağıtımı varsayılan başlatma sistemi olarak systemd kullanır. Systemd zamanlayıcıları (timers), crontab'a doğrudan alternatif olarak geliştirilmiştir ve sistem yöneticilerine çok daha ayrıntılı kontrol sunar.

Systemd timer mimarisinde iki farklı birim (unit) dosyası birlikte çalışır: görevin ne yapacağını tanımlayan bir .service dosyası ve bu servisin ne zaman tetikleneceğini belirleyen bir .timer dosyası. Bu ayrım sayesinde bir görevi zamanlayıcıdan bağımsız olarak systemctl start servisim.service komutuyla istediğiniz an elle test edebilirsiniz.

Systemd timer'ların sağladığı başlıca avantajlar şunlardır:

• Ayrıntılı Loglama: Görevin standart çıktısı ve hata mesajları otomatik olarak systemd-journald tarafından yakalanır. journalctl -u myjob.service komutuyla tüm çalışma tarihçesi filtrelenebilir.
• Kaynak Denetimi: Service dosyası içerisine CPUQuota=30% veya MemoryMax=512M gibi cgroups yönergeleri eklenerek zamanlanmış görevin sunucuyu kilitlemesi engellenir.
• Gelişmiş Zamanlama Sözdizimi: Yalnızca takvim saatleri değil, OnBootSec=15min (açılıştan 15 dakika sonra) veya OnUnitActiveSec=1h (önceki etkinleştirmeden 1 saat sonra) gibi göreceli aralıklar tanımlanabilir. Ayrıntılı karşılaştırma için cron vs systemd timer analizimizi inceleyebilirsiniz.

.service ve .timer Birimlerinin Oluşturulması

Systemd timer kurulumu iki dosya hazırlamayı gerektirir. İlk olarak görevi yürüten servis dosyasını /etc/systemd/system/cleanup.service yolunda oluşturun:

[Unit]
Description=Gecici Dizin Temizleme Servisi
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/find /tmp -type f -mtime +7 -delete

Ardından bu servisi her gün saat 04:00'te tetikleyen /etc/systemd/system/cleanup.timer dosyasını tanımlayın:

[Unit]
Description=Gunluk Temizlik Zamanlayicisi

[Timer]
OnCalendar=*-*-* 04:00:00
Persistent=true

[Install]
WantedBy=timers.target

Dosyaları kaydettikten sonra systemd daemon'ını yenileyip zamanlayıcıyı etkinleştirin:

sudo systemctl daemon-reload
sudo systemctl enable --now cleanup.timer

Sistemdeki tüm aktif zamanlayıcıların sonraki çalışma vaktini, kalan süreyi ve tetikleyeceği birimi doğrulamak için şu komutu çalıştırabilirsiniz:

systemctl list-timers --all

Bu komutun çıktısında yer alan NEXT sütunu görevin sonraki tetiklenme vaktini, LEFT sütunu kalan süreyi, LAST ve PASSED sütunları ise önceki çalışma zamanını net olarak gösterir.

Alternatif 2: Anacron (Sürekli Açık Olmayan Sistemler İçin)

Anacron, sürekli 7/24 çalışmayan masaüstü bilgisayarlar, dizüstü cihazlar ve mesai saatleri dışında kapatılan sunucular için özel olarak tasarlanmıştır. Standart cron bir arka plan süreci (daemon) olarak bellekte beklerken, anacron genellikle sistem açılışında veya belirli aralıklarla çalışıp görevleri kontrol eder.

Anacron yapılandırması /etc/anacrontab dosyasında tutulur ve sözdizimi standart crontab'dan farklıdır. Zaman aralıkları dakika veya saat cinsinden değil, yalnızca gün bazında belirtilir. Görev tanımı dört alandan oluşur: periyot (gün), gecikme (dakika), iş tanımlayıcısı ve çalıştırılacak komut.

# /etc/anacrontab ornegi
# periyot(gun)  gecikme(dk)  is-kimligi       komut
1               10           gunluk.yedek     /usr/local/bin/backup-daily.sh
7               20           haftalik.rapor   /usr/local/bin/weekly-report.sh

Yukarıdaki örnekte sistem açıldığında anacron /var/spool/anacron/gunluk.yedek dosyasındaki son çalışma tarihini kontrol eder. Son çalışmadan itibaren en az bir takvim günü geçmişse, anacron başladıktan 10 dakika sonra (sistemin açılış yükü azaldığında) yedekleme betiğini başlatır. Bu sayede dizüstü bilgisayarınız gece kapalı olsa bile sabah açıldığında kaçırılan yedekleme güvenle tamamlanır.

Alternatif 3: Uygulama İçi Zamanlayıcılar (Celery Beat, BullMQ, Hangfire)

Kısa yanıt: Görev uygulamanın ORM modellerine, servis katmanına veya iş mantığına doğrudan dokunuyorsa zamanlamayı uygulamanın içine taşıyın; dışarıdan kabuk komutu çağırmak bu erişimi sağlamaz ve ortam farkları yüzünden kolayca kırılır.

Modern web uygulamalarında zamanlanmış görevler genellikle veritabanı modellerine, harici API kimlik doğrulayıcılarına ve iş mantığına doğrudan erişim gerektirir. Bu senaryolarda kabuk komutu çalıştırmak yerine uygulama katmanı içinde çalışan zamanlayıcılar tercih edilir:

• Python / Django (Celery Beat): Zamanlanmış görevleri RabbitMQ veya Redis kuyruğuna aktarır. Görevler arka plandaki Celery worker'ları tarafından asenkron olarak tüketilir. Worker'lar yatayda ölçeklenebilir ve başarısız işler için otomatik yeniden deneme (retry) kuralları işletilebilir. Adım adım kurulum için Django Celery Beat kurulum rehberimize bakabilirsiniz.
• Node.js / TypeScript (BullMQ & Bree): Redis destekli BullMQ, saniye hassasiyetinde tekrarlanan işler, gecikmeli mesajlar ve öncelik kuyrukları sağlar. İş kilitleriyle worker'ları koordine eder; hata ve yeniden deneme durumlarında aynı iş tekrar işlenebilir.
• .NET (Hangfire & Quartz.NET): SQL Server veya Redis arkalığı ile çalışan Hangfire, kod içerisinden RecurringJob.AddOrUpdate çağrısıyla arka plan görevleri oluşturur ve yerleşik bir web yönetim paneli sunar. İki aracı seçme ölçütlerini Hangfire ve Quartz.NET karşılaştırmasında ayrıntılandırıyoruz.

Uygulama içi zamanlayıcıların en büyük dezavantajı işletim maliyetidir. Seçilen araca uygun kuyruk veya veritabanı arkalığının ayakta tutulması gerekir. Ayrıca uygulamanın bellek sızıntıları (memory leak) yaşaması durumunda zamanlayıcı süreci çökebilir ve tüm periyodik işler durabilir.

Alternatif 4: Bulut ve Web Tabanlı Zamanlayıcılar (cronjob.com.tr)

Kısa yanıt: Tetiklenecek şey zaten bir HTTPS uç noktasıysa zamanlamayı bulut tarafına taşıyın; sunucuda daemon kurmazsınız, taşınma ve ölçekleme sırasında zamanlama ayarı baştan yapılmaz.

Sunucunuzda crontab yapılandırma yetkiniz yoksa (örneğin kısıtlı paylaşımlı hosting veya cPanel ortamlarında), sunucusuz (serverless) AWS Lambda ve Google Cloud Functions kullanıyorsanız veya uygulamanız mikroservis mimarisindeyse en temiz alternatif dış web tabanlı cron servisleridir. AWS ve Google Cloud'un kendi zamanlayıcıları da benzer modeli sunar: AWS'de cron işi tanımlamayı ve Google Cloud Scheduler kurulumunu anlatan rehberlerimiz bu platformlarda kalmayı planlayanlar için hazırlanmıştır. Edge ağı üzerinde çalışan Cloudflare projelerinde ise Cloudflare Workers cron tetikleyicisi zamanlamayı wrangler.toml dosyası üzerinden tanımlar.

Harici bir web cron servisi sunucunuza SSH ile bağlanmaz; bunun yerine belirlediğiniz periyotta uygulamanızın güvenli HTTPS API uç noktasına bir HTTP isteği (GET, POST, PUT vb.) gönderir. Görev, HTTP isteğini karşılayan web uygulamanızın çalıştığı sunucuda işlenir.

Bu yaklaşımın sunduğu temel avantajlar:

• Sunucu Çöküşlerine Karşı Dayanıklılık: Yerel crontab sunucu çöktüğünde durur ve sizi haberdar edemez. Web tabanlı servis ise uç noktanıza ulaşamadığında ardışık hata eşiği üzerinden erişim sorunu uyarısı gönderir. Aynı iş için bildirimler arasında en az 60 dakika bulunur.
• Merkezi Yönetim: Onlarca farklı sunucudaki crontab dosyalarını ayrı ayrı yönetmek yerine tüm projelerinizin zamanlanmış görevlerini tek bir kontrol panelinden görebilirsiniz.
• Altyapı Bağımsızlığı: Sunucunuzu başka bir veri merkezine taşısanız veya Docker konteynerinizi sıfırdan dağıtsanız bile zamanlayıcı dışarıda çalıştığı için hiçbir cron ayarını baştan yapılandırmanız gerekmez.

Gerçek Senaryo: Depo Tabanlı Zamanlama (GitHub Actions ve GitLab)

Dağıtımınız zaten bir Git deposu üzerinden yapılıyorsa zamanlamayı da depoya taşımak pratik bir ara yoldur: ifade sürüm takibindedir, kod incelemesinden geçer ve yeni bir sunucuya taşınırken elle kopyalanmaz. İki yaygın kullanım GitHub Actions'ta zamanlanmış workflow kurmaktır ve GitLab pipeline schedule tanımlamaktır. GitHub Actions schedule ifadeleri varsayılan olarak UTC'dir; GitLab'da pipeline schedule oluştururken saat dilimi (Cron timezone) seçilir. Türkiye saatiyle 08:30 için GitHub'da 30 5 * * *, GitLab'da Europe/Istanbul seçilerek 30 8 * * * kullanılır.

GitHub tarafında tetikleme, workflow dosyasındaki on.schedule anahtarıyla tanımlanır. Aşağıdaki örnek iş günleri Türkiye saatiyle 08:30'da bir rapor uç noktasını çağırır; kimlik bilgileri depo ayarlarındaki Secrets içinde tutulur:

# .github/workflows/stok-raporu.yml
name: Stok raporu
on:
  schedule:
    - cron: "30 5 * * 1-5"   # UTC 05:30 = Turkiye saatiyle 08:30
jobs:
  rapor:
    runs-on: ubuntu-latest
    steps:
      - name: Rapor uc noktasini cagir
        run: |
          curl --fail-with-body -X POST "$RAPOR_URL" \
            -H "Authorization: Bearer $RAPOR_TOKEN"
        env:
          RAPOR_URL: ${{ secrets.RAPOR_URL }}
          RAPOR_TOKEN: ${{ secrets.RAPOR_TOKEN }}

GitLab'da cron ifadesi dosyada değil arayüzde tanımlanır: proje menüsünden Build > Pipeline schedules ekranında saat girilir ve isteğe bağlı saat dilimi seçilir. Pipeline'daki işin yalnızca bu zamanlanmış çalıştırmalarda koşması için kural eklenir:

# .gitlab-ci.yml - yalnizca zamanlanmis boru hattinda calisir
stok-raporu:
  script:
    - 'curl --fail-with-body -X POST "$RAPOR_URL" -H "Authorization: Bearer $RAPOR_TOKEN"'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'

Bu model günlük rapor üretimi, bağımlılık güncelleme ve geçici ortam temizliği gibi günde birkaç kez çalışacak işlere uyar; dakikalık izleme veya müşteriye dönük tetikleme için tasarlanmamıştır. Ayrıca GitHub, yoğun saatlerde schedule tetiklemelerini geciktirebilir ve herkese açık (public) depolarda 60 gün depo etkinliği olmazsa zamanlanmış workflow'ları otomatik devre dışı bırakır; kesin saat kritik olan işlerde harici HTTP zamanlayıcı daha öngörülebilir davranır.

Gerçek Kod Örnekleri

Aşağıda farklı ihtiyaçlara yanıt veren iki temel alternatifin çalışan yapılandırma örnekleri yer almaktadır.

1. Systemd ile Günlük Log Temizliği:

Aşağıdaki servis birimi /var/log/app dizininde 14 günden eski logları siler:

# /etc/systemd/system/app-log-clean.service
[Unit]
Description=Eski Uygulama Loglarini Temizleme Servisi

[Service]
Type=oneshot
ExecStart=/usr/bin/find /var/log/app -name "*.log" -type f -mtime +14 -delete
StandardOutput=journal
StandardError=journal

Bu servisi her gece 03:15'te çalıştıracak timer birimi:

# /etc/systemd/system/app-log-clean.timer
[Unit]
Description=Eski Loglari Gece Temizleme Zamanlayicisi

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

2. Tek Seferlik İleri Tarihli İşler İçin 'at' Komutu:

Linux sistemlerinde yinelenen bir takvim gerektirmeyen, yalnızca gelecekte belirli bir anda tek seferlik çalışacak işler için at komutu kullanılır. Örneğin 20 dakika sonra ağır bir arşivleme betiğini çalıştırmak için:

# 20 dakika sonra calisacak komutu zamanlama
echo "/usr/local/bin/create-archive.sh" | at now + 20 minutes

# Sirada bekleyen isleri listeleme
atq

# Bekleyen belirli bir isi iptal etme (ornek id: 4)
atrm 4

Zamanlayıcı Kurulumunu Doğrulama ve Sorun Giderme

Kısa yanıt: Hangi zamanlayıcıyı seçerseniz seçin doğrulama sırası aynıdır; önce zamanlamanın sisteme kayıtlı olduğunu, sonra görevi elle çalıştırabildiğinizi, en son da logda gerçekten tetiklendiğini kontrol edin. Bu üç adım, "çalışmıyor" şikayetlerinin büyük kısmını dakikalar içinde ayıklar.

Aşağıdaki tablo, geçiş sonrası en sık görülen belirtileri, olası nedenleri ve tek satırlık kontrol komutlarını bir araya getirir:

Aynı kontrollerin log tarafındaki karşılığı aşağıdaki gibidir. Bir crontab satırı tetiklendiğinde Ubuntu'da syslog'a CRON satırı düşer; systemd göreviyse journal kaydı oluşur:

$ grep CRON /var/log/syslog | tail -n 3
Oct 28 03:15:01 app01 CRON[21439]: (root) CMD (/usr/bin/find /var/log/app -type f -mtime +14 -delete)
Oct 28 03:15:01 app01 CRON[21438]: (CRON) info (No MTA installed, discarding output)
Oct 28 04:00:01 app01 CRON[21502]: (root) CMD (/usr/bin/php /var/www/app/cron.php)

$ journalctl -u cleanup.service --since "1 hour ago"
Oct 28 04:00:01 app01 systemd[1]: Starting cleanup.service - Gecici Dizin Temizleme Servisi...
Oct 28 04:00:01 app01 (find)[21504]: cleanup.service: Deactivated successfully.

Örnekteki (root) CMD (...) satırları komutun gerçekten tetiklendiğini kanıtlar. No MTA installed, discarding output satırı ise görevin bir çıktı ya da hata ürettiğini ama e-posta gönderilemediği için bu içeriğin çöpe gittiğini gösterir; hangisi olduğunu görmek için çıktıyı dosyaya yönlendirin. Journaldaki Deactivated successfully satırı oneshot servisin hata kodu sıfırla bittiğinin kanıtıdır; hata varsa burada Failed with result 'exit-code' görürsünüz.

Sık Karşılaşılan Hatalar ve Çözümleri

Geleneksel cron'dan alternatif zamanlayıcılara geçerken en sık karşılaşılan dört teknik hata ve bunların kesin çözüm adımları şunlardır:

1. Failed to start myjob.timer: Unit myjob.service not found
Nedeni: Systemd timer birimi varsayılan olarak kendi adıyla birebir eşleşen bir servis birimi arar. Örneğin myjob.timer dosyası myjob.service dosyasını tetikler. Servis dosyasının adı farklıysa veya dosya henüz oluşturulmamışsa bu hata döner.
Çözümü: Timer ve service dosya adlarını eşitleyin. Eğer farklı isimler kullanmak zorundaysanız .timer dosyasının [Timer] bölümüne Unit=gercek-servis-adi.service yönergesini açıkça ekleyin ve ardından sudo systemctl daemon-reload çalıştırın.

2. anacron: Can't open /var/spool/anacron/job
Nedeni: Anacron görevlerin son çalışma zaman damgalarını /var/spool/anacron dizinindeki dosyalarda saklar. Bu dizin silinmişse, salt okunur bir dosya sistemine bağlıysa veya anacron'u çalıştıran kullanıcının yazma yetkisi yoksa bu hata oluşur.
Çözümü: Dizinin varlığını ve sahipliğini kontrol edin. Dizin eksikse sudo mkdir -p /var/spool/anacron komutuyla oluşturun, sahipliğini root kullanıcısına verin (sudo chown root:root /var/spool/anacron) ve izinleri sudo chmod 755 /var/spool/anacron olarak ayarlayın.

3. Dağıtık Kümede Cron Çakışması (Race Condition)
Nedeni: Uygulamanız Kubernetes, Docker Swarm veya çoklu sanal sunucu üzerinde küme (cluster) halinde çalışırken her sunucunun yerelinde cron çalışmasıdır. Örneğin günlük abonelik ücreti tahsilatı her sunucuda aynı anda tetiklenerek müşteriden mükerrer para çekilmesine neden olabilir.
Çözümü: Zamanlamayı yerel sunuculardan çıkarıp merkezi bir noktaya taşıyın. Ya Redis tabanlı dağıtık kilit mekanizması (Redlock) kurun ya da tüm sunucuların önündeki yük dengeleyiciye harici bir web cron servisi (cronjob.com.tr) üzerinden tek bir HTTP isteği gönderilmesini sağlayın.

4. Bellek Şişmesi (Memory Leak) ve Süreç Çökmesi
Nedeni: Node.js, Python veya PHP ile yazılmış uygulama içi zamanlayıcıların günlerce kesintisiz ayakta kalması sırasında kapatılmayan veritabanı bağlantıları veya temizlenmeyen değişkenler nedeniyle RAM tüketiminin sürekli artmasıdır. Sistem yetersiz bellek nedeniyle süreci (OOM Killer) aniden sonlandırır.
Çözümü: Sürekli çalışan bir uygulama süreci yerine, her çalıştırmada ayağa kalkıp işi bitince kapanan izole bir komut yapısı kurun. Alternatif olarak web uygulamanızı standart HTTP istekleriyle tetikleyerek bellek yönetimini web sunucusunun (FPM veya Nginx worker geri dönüşümü) yönetimine bırakın.

cronjob.com.tr ile HTTP Tabanlı Alternatif Kurulum

Sunucunuzda hiçbir arka plan süreci (daemon), crontab dosyası veya systemd birimiyle uğraşmadan zamanlanmış görevlerinizi bulut üzerinden yönetebilirsiniz. HTTP tabanlı bir iş kurmak için aşağıdaki adımları izleyin:

1. Uygulamanızda zamanlanmış görevi yürütecek güvenli bir HTTPS uç noktası hazırlayın (örneğin https://api.siteniz.com/cron/cleanup). Bu adresi yetkisiz kişilerin tetiklemesini engellemek için özel bir başlık (örneğin X-Cron-Token: gizli-anahtariniz) kontrolü ekleyin.
2. cronjob.com.tr paneline giriş yapın ve 'Yeni İş Ekle' butonuna tıklayın. Kayıt tamamen ücretsizdir ve kredi kartı bilgisi istenmez.
3. Görevinizin URL adresini girin, HTTP metodunu (GET, POST, PUT, DELETE vb.) seçin ve yetkilendirme başlığınızı ekleyin. Zamanlama olarak hazır aralıklardan birini seçebilir veya crontab sözdizimi kurallarına uygun beş alanlı bir cron ifadesi tanımlayabilirsiniz. Varsayılan saat dilimi Europe/Istanbul'dur.
4. İşi kaydedip paneldeki manuel çalıştırma seçeneğiyle bir istek gönderin. Dönen durum kodunun 200–399 aralığında olduğunu ve yanıt süresini doğrulayın. Ardından görevi etkinleştirin.

cronjob.com.tr üzerinde minimum çalıştırma aralığı 60 saniyedir (1 dakika). Yanıt bekleme süresi (timeout) seçilen aralığa göre otomatik belirlenir: aralıktan 5 saniye çıkarılarak hesaplanır (en az 5, en fazla 290 saniye). Örneğin 1 dakikalık görevlerde 55 saniye, 2 dakikalık görevlerde 115 saniye, 5 dakika ve üzeri hazır aralıklarda ve 5 alanlı cron ifadeli işlerde 290 saniye yanıt beklenir. HTTP 200–399 aralığındaki yanıtlar başarılı kabul edilir.

Her çalıştırmanın durum kodu, yanıt süresi ve gövdesinin ilk ~64 KB'lık bölümü 7 gün boyunca loglarda saklanır. Ardışık hata sayısı eşiği (varsayılan 3, 1–20 arasında ayarlanabilir) aşıldığında sistem kayıtlı e-posta adresinize erişim sorunu uyarısı iletir; kesinti giderildiğinde ise kesinti süresi bilgisiyle birlikte düzeldi e-postası gönderilir.

Sıkça Sorulan Sorular (SSS)

Systemd timer cron'un yerini tamamen alabilir mi?

Evet, modern Linux dağıtımlarında systemd timer'lar cron'un yerini tamamen alabilir. Servis bağımlılık kontrolü, hassas zamanlama, cgroups ile kaynak sınırlama ve journalctl ile yerel loglama gibi üstünlükler sunar.

Anacron ile Cron arasındaki en temel fark nedir?

Cron bilgisayar kapalıysa görevi kaçırır ve sonradan telafi etmez; Anacron ise bilgisayar açıldığında kaçırılan günlük veya haftalık görevi otomatik olarak çalıştırır.

Web tabanlı cron servisi kullanmanın avantajı nedir?

Sunucudan bağımsızdır; sunucuda cron daemon yönetimi gerektirmez, sunucu erişilemez olduğunda e-posta uyarısı verir ve tüm projeleri tek bir merkezi panelden yönetmenizi sağlar.

Tek seferlik ileri tarihli bir iş için ne kullanılır?

Tek seferlik zamanlanmış görevler için Linux'ta at komutu kullanılır; yinelenen bir takvim oluşturmadan belirlenen saat veya sürede komutu bir defa çalıştırıp sonlanır.

Zamanlanmış GitHub Actions işleri tam dakikinde çalışır mı?

Hayır. GitHub yoğun saatlerde schedule tetiklemelerini dakikalar hatta daha uzun süre geciktirebilir. Ayrıca herkese açık (public) depolarda 60 gün depo etkinliği olmazsa zamanlanmış workflow'lar otomatik olarak devre dışı kalır; kesin saat kritik olan işlerde harici HTTP zamanlayıcı daha öngörülebilir davranır.

Systemd timer'ın bir sonraki çalışma saatini nasıl önceden görürüm?

systemctl list-timers --all komutunun NEXT sütunu tüm etkin zamanlayıcıların sıradaki tetiklenme vaktini, LEFT sütunu kalan süreyi gösterir. Takvim ifadesinin gelecekteki eşleşmelerini systemd-analyze calendar '*-*-* 04:00:00' komutu listeler.

İlgili Rehberler