cPanel'de Cron Job Kurma: Zamanlanmış Görevi Adım Adım Ayarlama

cPanel'de Cron Jobs ekranını ilk kez açtığınızda karşınıza sarı bir uyarı kutusu, beş küçük açılır menü ve tek satırlık boş bir "Command" alanı çıkar. Kafa karıştıran kısım genellikle zaman ayarı değildir — "Twice Per Hour" gibi hazır şablonlar zaten menüde durur. Asıl takıldığınız yer o boş komut satırıdır: oraya php script.php mı yazacaksınız, /usr/local/bin/php mi, yoksa wget https://siteniz.com/cron.php mi? Ve bir kez kaydettikten sonra, görevin gerçekten çalışıp çalışmadığını nereden anlayacaksınız?

Bu yazı tam olarak o boş komut satırının etrafında dönüyor. Zaman formatını beş alanda okumayı, komut alanında PHP dosyasını doğrudan çalıştırmakla URL çağırmak arasındaki farkı ve hangisinin ne zaman doğru cevap olduğunu, sunucudaki gerçek PHP yolunu bulmayı, her çalıştırmada gelen e-posta yağmurunu kesmeyi ve en sonunda görevin çalıştığını kendi log dosyanızdan kanıtlamayı adım adım ele alacağız.

Anlatım cPanel arayüzü üzerinden ilerliyor, ancak komutlar standart Linux cron sözdizimidir; sunucuya SSH ile bağlanıp crontab -e kullanıyorsanız da aynı satırlar geçerlidir. Cron'un komut satırı tarafındaki genel mantığı için Linux'ta cron görevleri yazısı iyi bir tamamlayıcıdır.

cPanel'de Cron Jobs Ekranı Nerede ve Neye Benzer?#

cPanel ana ekranında Gelişmiş (Advanced) bölümünün altında Cron Jobs simgesi bulunur. Sayfa üç parçadan oluşur:

1. Cron Email: En üstteki tek satırlık kutu. Görev çıktı ürettiğinde raporun gideceği adres burasıdır. Boş bırakılabilir.
2. Add New Cron Job: Ortadaki form. Bir "Common Settings" açılır menüsü, ardından dakika/saat/gün/ay/haftanın günü için beş ayrı menü ve en altta "Command" alanı.
3. Current Cron Jobs: Kayıtlı görevlerin listesi. Düzenle ve sil butonları buradadır.

Bazı paylaşımlı paketlerde bu simge hiç görünmez; hosting sağlayıcısı cron erişimini kapatmış olabilir veya paketin kaynak limitleri buna izin vermiyordur. Simgeyi göremiyorsanız yapılandırma hatası aramadan önce destek ekibine sorun.

En kısa çalışma aralığı da pakete göre değişir. Çoğu paylaşımlı sunucuda dakikada bir çalışan görevlere izin verilmez; alt sınır 5 veya 15 dakikadır. Formda dakikada bir tanımlayıp kaydedebilseniz bile sunucu tarafındaki bir politika görevi seyreltebilir ya da hesabınız kaynak limitlerine takılabilir.

Cron Zaman Formatını Beş Alanda Okumak#

Cron satırının solundaki beş alan her zaman aynı sıradadır. cPanel bunları ayrı menülere böler, ancak kaydettiğinde tek satıra dönüşür:

* * * * *  komut
│ │ │ │ │
│ │ │ │ └── Haftanın günü (0-7, 0 ve 7 = Pazar)
│ │ │ └──── Ay (1-12)
│ │ └────── Ayın günü (1-31)
│ └──────── Saat (0-23)
└────────── Dakika (0-59)

Alanların içinde dört işaret kullanılır:

Pratikte en çok kullanılan kalıplar şunlardır:

⚠️ Sık yapılan iki hata var. Birincisi: */5 * * * * ile 5 * * * * aynı şey değildir — ilki beş dakikada bir, ikincisi her saatin sadece 5. dakikasında çalışır. İkincisi: ayın günü ve haftanın günü alanlarının ikisi birden doluysa cron bunları "VE" değil "VEYA" olarak yorumlar. 0 0 13 * 5 satırı ayın 13'ünde veya her Cuma çalışır, sadece 13'üne denk gelen Cuma'da değil.

Bir de zaman dilimi meselesi vardır. Cron, sunucunun sistem saatine göre çalışır; PHP tarafındaki date.timezone ayarını umursamaz. Sunucu UTC'ye ayarlıysa 0 3 * * * satırı Türkiye saatiyle 06:00'da tetiklenir. Emin olmak için SSH erişiminiz varsa date komutunun çıktısına bakın, yoksa bir test görevine tarih damgası bastırın (aşağıdaki log bölümünde nasıl yapıldığı var).

Komut Alanına Ne Yazılır: php-cli mi, wget/curl mi?#

Bu, tüm yazının en kritik kararıdır ve çoğu rehber üstünden atlayarak geçer. Bir PHP dosyasını zamanlı çalıştırmanın iki yolu vardır ve ikisi tamamen farklı ortamlar üretir:

# Yol 1: PHP dosyasını doğrudan komut satırından çalıştır (php-cli)
/usr/local/bin/php /home/kullanici/public_html/gorevler/rapor.php

# Yol 2: Dosyayı web sunucusu üzerinden bir HTTP isteğiyle çağır
/usr/bin/curl -s https://ornek.com/gorevler/rapor.php

Birinci yolda dosya Apache'ye hiç uğramaz; PHP'nin komut satırı sürümü tarafından yorumlanır. İkinci yolda ise sunucu kendi kendine bir web isteği atar, istek Apache'den geçer, PHP-FPM tarafından işlenir ve tıpkı bir ziyaretçinin sayfayı açması gibi davranır. Aradaki farklar tabloya sığmayacak kadar önemlidir:

php-cli Ne Zaman Doğru Seçim?#

Görev uzun sürüyorsa, çok bellek yiyorsa veya dışarıya asla açılmaması gerekiyorsa doğru cevap php-cli'dir. Veritabanı temizliği, toplu e-posta kuyruğu işleme, gece yedeği alma, rapor üretme gibi işler bu gruba girer. Dosyayı public_html dışında bir klasöre koyabilirsiniz — böylece hiçbir ziyaretçi ona URL üzerinden ulaşamaz:

/usr/local/bin/ea-php82 /home/kullanici/gorevler/temizlik.php

Bir uyarı: CLI'da çalışan bir betiğin çalışma dizini $HOME olur, betiğin bulunduğu klasör değil. Kodunuz require 'config.php' gibi göreli yollar kullanıyorsa dosyayı bulamaz. İki çözümden birini uygulayın:

# Çözüm A: Önce doğru klasöre geç, sonra çalıştır
cd /home/kullanici/public_html && /usr/local/bin/php gorevler/rapor.php

# Çözüm B: PHP tarafında __DIR__ kullan (kod içinde)
# require __DIR__ . '/config.php';

wget veya curl Ne Zaman Doğru Seçim?#

Betik, uygulamanın web bağlamına gerçekten muhtaçsa URL çağırmak mantıklıdır. Bazı hazır CMS ve eklentiler $_SERVER['HTTP_HOST'] üzerinden site adresini üretir, .htaccess yönlendirmelerine güvenir ya da yalnızca framework'ün web önyükleme dosyası (index.php) üzerinden başlatılabilecek şekilde yazılmıştır. Böyle bir kodu CLI ile çağırdığınızda "undefined index HTTP_HOST" gibi hatalar alırsınız.

# curl: çıktıyı yutar, sadece tetikler
/usr/bin/curl -s -o /dev/null https://ornek.com/cron/gunluk.php

# wget: aynı işi yapan alternatif
/usr/bin/wget -q -O /dev/null https://ornek.com/cron/gunluk.php

URL çağırıyorsanız iki noktaya dikkat edin. Birincisi, adresi mutlaka çift tırnak içine alın ve & içeren sorgu parametrelerini öyle yazın; tırnaksız bir & komutu arka plana atar ve görev yarım kalır. İkincisi, crontab dosyasında % karakteri özel anlamlıdır (satır sonu olarak yorumlanır) ve \% şeklinde kaçırılmalıdır:

/usr/bin/curl -s -o /dev/null "https://ornek.com/cron.php?anahtar=gizli123&mod=tam"

URL yöntemini seçtiyseniz betiği mutlaka bir gizli anahtarla koruyun. Aksi halde adresi öğrenen biri görevinizi dakikada yüzlerce kez tetikleyip hesabınızı limite sokabilir. HTTP istekleriyle ilgili bayrakların ayrıntısı için curl ile HTTP istekleri yazısına bakabilirsiniz.

Sunucudaki Doğru PHP Yolunu Bulmak#

Komut alanına sadece php yazmak paylaşımlı sunucularda genellikle işe yaramaz; cron ortamının PATH değişkeni kabuğunuzunkiyle aynı değildir. Tam yol vermek gerekir. cPanel sunucularında PHP genelde şu konumlardan birindedir:

Hangisinin sizde geçerli olduğunu bulmanın en temiz yolu cPanel Terminal veya SSH erişimidir:

# Varsayılan PHP hangisi ve sürümü ne?
which php
php -v

# Çalışan ikilinin gerçek yolunu PHP'nin kendisine sordur
php -r 'echo PHP_BINARY, PHP_EOL;'

# Sunucuda kurulu tüm EasyApache sürümlerini listele
ls -1 /opt/cpanel/ | grep ea-php

SSH erişiminiz yoksa yolu bir defalık cron göreviyle öğrenebilirsiniz. Aşağıdaki satırı ekleyin, bir kez çalışmasını bekleyin, sonucu okuyun ve görevi silin:

/usr/local/bin/php -r 'echo PHP_BINARY."\n".PHP_VERSION."\n".PHP_SAPI."\n";' >> $HOME/php-yolu.txt 2>&1

Çıktıdaki üçüncü satırın cli yazması önemlidir. cgi-fcgi görüyorsanız web sürümünü çalıştırıyorsunuz demektir ve süre/bellek limitleri farklı davranacaktır.

⚠️ cPanel'in MultiPHP Manager'ından sitenizin sürümünü değiştirmek cron satırınızı otomatik güncellemez. Komutta ea-php74 gibi sabit bir sürüm yazdıysanız ve sunucudan PHP 7.4 kaldırıldıysa görev "No such file or directory" ile sessizce ölür. Sürüm geçişlerinde cron satırlarını da gözden geçirin; sürüm yönetiminin ayrıntıları PHP sürüm yönetimi yazısında.

Her Çalıştırmada Gelen Mail Bombardımanını Kesmek#

Cron'un varsayılan davranışı şudur: komut ekrana bir şey yazdıysa, bu çıktıyı e-posta ile gönderir. Bir satırlık "Bağlantı kuruldu" mesajı bile çıktı sayılır. 5 dakikada bir çalışan bir görev, günde 288 e-posta demektir — ve bu kutular genellikle hesabın disk kotasını doldurarak asıl e-postalarınızın da reddedilmesine yol açar.

Susturmanın üç yolu vardır ve hangisini seçeceğiniz neyi kaybetmeyi göze aldığınıza bağlıdır:

# 1) Her şeyi sustur: normal çıktı da hata da çöpe gider
/usr/local/bin/php $HOME/gorevler/rapor.php >/dev/null 2>&1

# 2) Sadece normal çıktıyı sustur, hataları e-posta olarak al
/usr/local/bin/php $HOME/gorevler/rapor.php >/dev/null

# 3) Her şeyi kendi log dosyana yaz, e-posta hiç gelmesin
/usr/local/bin/php $HOME/gorevler/rapor.php >> $HOME/logs/rapor.log 2>&1

Buradaki 2>&1, "hata akışını (2) normal çıktı akışına (1) yönlendir" demektir ve sıralaması önemlidir: 2>&1 >/dev/null yazarsanız hatalar yine e-posta olarak gelir, çünkü yönlendirme sırası tersine döner.

cPanel arayüzünde ayrıca sayfanın en üstünde Cron Email kutusu bulunur. Buradaki adresi silip kaydederseniz o hesaptaki tüm görevler için e-posta gönderimi kapanır. Ham crontab dosyasında bunun karşılığı en üste eklenen boş bir MAILTO satırıdır:

MAILTO=""
*/15 * * * * /usr/local/bin/php $HOME/gorevler/kuyruk.php >/dev/null 2>&1

Tavsiyem üçüncü yöntemdir. E-postayı tamamen kesip çıktıyı log dosyasına yazmak, hem gelen kutunuzu temiz tutar hem de "bu görev ne zaman çalıştı" sorusuna dosyaya bakarak cevap vermenizi sağlar.

Görevin Gerçekten Çalıştığını Nasıl Doğrularsınız?#

Paylaşımlı hostingde /var/log/cron dosyasını okuma yetkiniz yoktur; sistem cron loglarına erişemezsiniz. Bu yüzden "çalıştı mı?" sorusunun tek güvenilir cevabı, görevin kendi kanıtını üretmesidir.

Adım 1 — Log klasörü hazırlayın. Ev dizininizde logs adında bir klasör oluşturun. public_html içine koymayın; log dosyaları çoğu zaman veritabanı hatası, dosya yolu, hatta parça parça sorgu içerir ve web'den okunabilir olmamalıdır.

Adım 2 — Her çalıştırmaya tarih damgası bastırın. Crontab içinde % karakterini kaçırmayı unutmayın:

*/15 * * * * echo "--- $(date '+\%F \%T') basladi" >> $HOME/logs/kuyruk.log; /usr/local/bin/php $HOME/gorevler/kuyruk.php >> $HOME/logs/kuyruk.log 2>&1

Adım 3 — Dosyayı okuyun. SSH'niz varsa canlı takip edin, yoksa cPanel Dosya Yöneticisi'nden açın:

# Son satırları izle
tail -n 50 ~/logs/kuyruk.log

# Yeni satırları anlık olarak takip et
tail -f ~/logs/kuyruk.log

Adım 4 — Uygulama tarafındaki hataları ayrı okuyun. PHP ölümcül bir hata verdiyse bu bazen log dosyanıza değil, hesabınızın hata kayıtlarına düşer. cPanel'in hata kayıtları ekranı bu yüzden ikinci durağınızdır.

Adım 5 — Log dosyasının büyümesini sınırlayın. Her çalıştırmada yazan bir görev aylar içinde yüzlerce megabayta ulaşır ve disk kotanızı yer. Basit bir çözüm, ayda bir çalışan ikinci bir görevle dosyayı sıfırlamaktır:

0 4 1 * * : > $HOME/logs/kuyruk.log

Bir de üst üste binme sorunu vardır: 15 dakikada bir çalışan bir görev 20 dakika sürerse, ikinci kopya birincisi devam ederken başlar. Aynı veritabanı satırlarını iki işlem birden işlerse çift kayıt üretirsiniz. Sunucuda flock varsa kilit kullanın:

*/15 * * * * /usr/bin/flock -n $HOME/tmp/kuyruk.lock /usr/local/bin/php $HOME/gorevler/kuyruk.php >> $HOME/logs/kuyruk.log 2>&1

-n bayrağı, kilit meşgulse beklemeden çıkmasını sağlar; böylece görevler kuyruğa yığılmaz.

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

Belirti: Görev listede duruyor ama hiç çalışmıyor, log dosyası da oluşmuyor. Sebep: Komuttaki PHP yolu yanlış ya da o sürüm sunucudan kaldırılmış. Çözüm: /usr/local/bin/php gibi sarmalayıcı bir yolla test edin. Hata mesajını görebilmek için geçici olarak 2>&1 yönlendirmesini bir log dosyasına verin.

Belirti: "Permission denied" hatası geliyor. Sebep: Betiği doğrudan ./script.php gibi çalıştırmaya çalışıyorsunuz ve dosyanın çalıştırma izni yok. Çözüm: Betiği yorumlayıcıyla çağırın: php /tam/yol/script.php. PHP dosyalarına 755 izni vermek gerekmez, 644 yeterlidir.

Belirti: Tarayıcıda çalışan betik cron'da "Class not found" veya "Undefined index" veriyor. Sebep: Kod web bağlamına bağımlı; $_SERVER['DOCUMENT_ROOT'] veya HTTP_HOST kullanıyor. Çözüm: Ya kodda __DIR__ tabanlı yollara geçin, ya da görevi curl ile URL üzerinden çağırın.

Belirti: Görev yarıda kesiliyor, log dosyası cümlenin ortasında bitiyor. Sebep: URL yöntemi kullanılıyor ve web zaman aşımına takılıyor; ya da bellek limiti aşıldı. Çözüm: php-cli yöntemine geçin. Bellek sorunu sürüyorsa PHP bellek limiti ayarlarını CLI tarafı için gözden geçirin.

Belirti: Görev beklediğinizden üç saat önce/sonra çalışıyor. Sebep: Sunucu saat dilimi UTC. Çözüm: Cron satırını sunucu saatine göre hesaplayın veya betiğin başında date_default_timezone_set('Europe/Istanbul'); çağırın.

WordPress ve Laravel İçin Pratik Cron Örnekleri#

WordPress'in yerleşik zamanlayıcısı ziyaretçi trafiğine bağlı çalışır: kimse siteye girmezse zamanlanmış görev de tetiklenmez, çok ziyaretçi varsa gereksiz yere defalarca tetiklenir. Doğru kurulum, yerleşik zamanlayıcıyı kapatıp işi gerçek cron'a devretmektir.

Önce wp-config.php dosyasına şu satırı ekleyin:

define('DISABLE_WP_CRON', true);

Sonra cPanel'de tek bir görev tanımlayın:

*/10 * * * * /usr/local/bin/php $HOME/public_html/wp-cron.php >/dev/null 2>&1

Laravel'de ise tüm zamanlanmış işler tek bir giriş noktasından yönetilir. Sunucuya yalnızca şu satır eklenir; geri kalan zamanlama kodun içindedir:

* * * * * /usr/local/bin/php $HOME/uygulama/artisan schedule:run >> /dev/null 2>&1

Paylaşımlı pakette dakikada bir çalışmaya izin verilmiyorsa */5 kullanın; Laravel kaçırılan işleri bir sonraki turda değerlendirir, ancak dakikalık hassasiyet gerektiren görevleriniz varsa sanal sunucuya geçmek daha doğru bir karardır.

Sıkça Sorulan Sorular#

cPanel cron job neden hiç çalışmıyor?#

En yaygın üç sebep şunlardır: komuttaki PHP yolu yanlış veya kaldırılmış bir sürümü işaret ediyor; betiğin göreli yolları CLI'da çözülemiyor; ya da hosting paketinde cron erişimi hiç açık değil. Teşhis için komutun çıktısını geçici olarak bir log dosyasına yönlendirin ve gerçek hata mesajını okuyun. Hiçbir dosya oluşmuyorsa görev hiç tetiklenmiyor demektir; bu durumda paket sınırlarını sağlayıcınıza sorun.

Cron job'dan gelen e-postaları nasıl durdururum?#

İki yöntem var. cPanel'de Cron Jobs sayfasının üstündeki Cron Email kutusunu boşaltıp kaydederseniz o hesaptaki tüm görevlerin e-postası kesilir. Tek bir görev için ise komutun sonuna >/dev/null 2>&1 ekleyin. Hataları yine de görmek istiyorsanız çıktıyı çöpe göndermek yerine >> $HOME/logs/gorev.log 2>&1 ile kendi log dosyanıza yazın.

php-cli mi kullanmalıyım, wget mi?#

Görev uzun sürüyorsa, çok bellek tüketiyorsa veya dışarıya kapalı kalması gerekiyorsa php-cli daha doğrudur; web zaman aşımına takılmaz ve bir web işçisini meşgul etmez. Betik $_SERVER['HTTP_HOST'] gibi web değişkenlerine ya da .htaccess yönlendirmelerine bağımlıysa wget veya curl ile URL çağırmak gerekir. Bu durumda adresi mutlaka gizli bir anahtarla koruyun.

Cron görevinin çalıştığını nasıl doğrularım?#

Paylaşımlı hostingde sistem cron loglarını okuyamazsınız, bu yüzden görevin kendi kanıtını üretmesi gerekir. Komutun çıktısını ev dizininizdeki bir log dosyasına yönlendirin ve başına tarih damgası ekleyin. Dosyada yeni satırlar birikiyorsa görev çalışıyordur. Log dosyasını public_html dışında tutun ve ayda bir sıfırlayan ikinci bir görevle boyutunu sınırlayın.

cPanel'de dakikada bir çalışan cron kurabilir miyim?#

Teknik olarak form buna izin verse de çoğu paylaşımlı pakette alt sınır 5 veya 15 dakikadır; sağlayıcı bu politikayı sunucu tarafında uygular. Dakikalık hassasiyete gerçekten ihtiyaç duyan bir uygulamanız varsa (kuyruk işleme, anlık bildirim gönderimi) sanal sunucu tarafına geçmek daha sağlıklıdır. Orada hem aralık serbesttir hem de systemd zamanlayıcıları gibi ek seçenekleriniz olur.

Aynı cron görevi üst üste çalışırsa ne olur?#

Önceki çalıştırma bitmeden yenisi başlarsa iki işlem aynı veritabanı satırlarını işleyebilir; çift kayıt, çift e-posta veya bozuk dosya üretirsiniz. Sunucuda flock mevcutsa komutu kilitle sarmalayın: kilit meşgulken yeni kopya -n bayrağı sayesinde beklemeden çıkar. Alternatif olarak betiğin başında bir kilit dosyası oluşturup sonunda silmek de aynı işi görür.