Kısa cevap: cPanel’de cron kaydının görünmesi, uygulamanın işi tamamladığını kanıtlamaz. Önce neyin ne zaman oluşmasını beklediğinizi yazın; sonra zamanlama, çalıştırılan komut ve uygulama çıktısını ayrı kontrol edin. Çözüm olarak aynı görevi tekrar tekrar eklemeyin veya bütün bildirimleri kapatmayın.
Bir raporun hazırlanması, içerik eşitlemesi veya uygulama içindeki periyodik kontrol zamanlanmış bir işe bağlı olabilir. Ancak hangi komutun gerektiğini cPanel değil uygulamanın kendi çalışma biçimi belirler. Bu rehber, kendi hosting hesabını yöneten kullanıcının güvenli tanı kaydı hazırlaması içindir; bilinmeyen betikleri çalıştırmayı veya hizmet sınırlarını aşmayı önermez.
Önce beklenen sonucu tanımlayın
“Çalışmıyor” demek yerine oluşması gereken raporun adını, beklenen zamanı ve son başarılı işlemi not edin. Görevin yalnız kontrol yapıp değişiklik bulmadığı için çıktı üretmemesi ile hiç başlayamaması aynı durum değildir. Uygulamanın işlem geçmişini varsa inceleyin; tahmin yerine gözlenebilir bir sonuç belirleyin.
Örneğin her sabah hazırlanması beklenen bir dosya için yalnız dosyanın varlığına değil son değişiklik zamanına da bakın. Eski rapor duruyor olabilir. Hassas müşteri verisi yerine güvenli bir test çıktısı kullanın. Testin gerçek e-posta göndermesi veya stok değiştirmesi gibi yan etkileri varsa üretimde rastgele tekrar çalıştırmayın.
Doğru hesap ve mevcut görevler
Doğru cPanel hesabında olduğunuzu kontrol edin ve mevcut kayıtları inceleyin. Aynı betik farklı aralıklarla birden fazla kez eklenmiş olabilir. cPanel Cron Jobs belgesi, özelliğin sağlayıcı tarafından açılıp kapatılabildiğini ve çok sık görevlerin önceki iş bitmeden başlayarak performansı etkileyebileceğini açıklar.
Mevcut komutu ve zamanlamayı değiştirmeden önce güvenli bir kayıt alın. Bu kayda erişim anahtarı veya parola dahil etmeyin. cPanel rehberimiz hesabın yönetim alanlarını tanıtır; WHM yönetici görevleri ile kendi hesabınızdaki uygulama görevlerini birbirine karıştırmayın.
Dosya yolu ve PHP sürümü aynı soru değildir
cPanel’in görev oluşturma yönergesi, komutta betiğin tam yolunu kullanmayı ve belirli PHP sürümü gerekiyorsa buna uygun çalıştırıcı yolunu seçmeyi gösterir. Belgedeki örnekleri kendi kullanıcı adınıza, sürümünüze ve uygulamanıza uyarlamadan çalıştırmayın; sağlayıcınızdan doğru yolu doğrulatın.
Dosyanın tarayıcıdan açılmasıyla komut satırından çalışması aynı test değildir. Uygulamanın hangi sürümü desteklediğini ve cron için hangi giriş noktasını önerdiğini kendi resmî belgesinden öğrenin. Yalnız yeni bir sürüm göründüğü için çalıştırıcıyı değiştirmeyin. Mevcut siteyi etkileyebilecek ayar değişikliğini görev tanısından ayrı planlayın.
Zamanlama ile çalışma süresini birlikte düşünün
Görevin kaç dakikada bir başladığını bilmek kadar bir çalışmanın ne zaman bittiğini bilmek de önemlidir. Uygulama uzun süren bir işlem yapıyorsa daha sık başlatmak sorunu çözmek yerine aynı işi çoğaltabilir. Uygulamanın çakışmayı nasıl yönettiğini öğrenin; her programda aynı kilit veya kuyruk davranışı olduğunu varsaymayın.
Zamanı değerlendirirken sunucu ile sizin yerel saatinizin aynı olduğunu kabul etmeyin. Saat dilimi ve zaman kontrolü rehberi bu ayrımı açıklar; paylaşımlı hostingde sistem saatini değiştirmeye çalışmak yerine sağlayıcınızdan görevin hangi saat dilimine göre değerlendirildiğini öğrenin. Aynı günlük işin tatil veya yoğunluk nedeniyle farklı davranıp davranmadığını da uygulama tarafında inceleyin.
E-posta ve gerçek başarı ayrı kontrol edilmeli
Bildirim bekliyorsanız hesabın ilgili ayarını ve uygulamanın gerçekten çıktı üretip üretmediğini kontrol edin. Sessizlik başarı garantisi değildir. Hata kaydını ortadan kaldırmak için bütün çıktıları susturmak tanıyı zorlaştırabilir. Öte yandan komut çıktısında kişisel veri veya erişim bilgisi bulunuyorsa bunu geniş bir posta listesine göndermeyin.
Gelen kutusuna ulaşma sorunu ayrıca varsa e-posta gönderim kontrol rehberini kullanın. E-posta teslimatı ile zamanlanmış görevin tamamlanmasını tek sonuç olarak değerlendirmeyin. Hata mesajını paylaşırken adresleri ve gizli alanları gerektiği ölçüde maskeleyin.
Küçük değişiklik, ölçülebilir sonuç
Bir seferde tek bir kontrolü ilerletin. Önce yol yanlışlığını araştırırken aynı anda zamanlamayı ve PHP sürümünü değiştirmeyin. Test ortamı gerekiyorsa test sitesi hazırlığı rehberindeki ayrımı düşünün. WordPress kullanmayan uygulamada kendi test ve geri dönüş yöntemini esas alın; test ortamının gerçek müşterilere mesaj göndermediğini doğrulayın.
Destek talebine görev aralığını, uygulama adını, son başarılı zamanı ve hassas olmayan hata bilgisini ekleyin. Gerekiyorsa komutu gizli değerleri çıkararak paylaşın. Web hosting kapsamını değerlendirirken cron erişimi ve kullanım koşullarını ayrıca sorun. Yeni paket satın almak yerine önce belirli hatayı çözmek daha doğru başlangıç olabilir.
Sıkça Sorulan Sorular
Cron Jobs menüsü görünmüyorsa ne yapmalıyım?
Özelliğin hesabınızda açık olup olmadığını sağlayıcınıza sorun. Menü görünmemesi tek başına sunucu arızası anlamına gelmez; paket ve özellik kapsamı doğrulanmalıdır.
Görevi kaydetmek çalıştığını kanıtlar mı?
Hayır. Kaydın varlığı ile uygulamanın işi tamamlaması farklıdır. Beklenen çıktı, kayıt zamanı ve varsa hata mesajını ayrıca doğrulayın.
Tarayıcıda çalışan PHP dosyası cron ile de çalışır mı?
Bunu varsaymayın. Çalıştırma komutu, dosya yolu ve PHP sürümü ayrı kontrol gerektirir. Uygulamanın belgelenmiş zamanlanmış görev yöntemini kullanın.
Her dakika çalıştırmak daha iyi mi?
Her zaman değil. Önceki iş bitmeden yenisi başlarsa çakışma olabilir. Uygulamanın gereğini, çalışma süresini ve hizmet kurallarını birlikte değerlendirin.
Hata e-postası gelmiyorsa görev başarılı mı?
Hayır. Bildirim ayarı, komutun ürettiği çıktı ve uygulamanın gerçek sonucu farklıdır. E-posta yokluğunu tek başarı ölçütü olarak kullanmayın.
Aynı görevi tekrar ekleyeyim mi?
Önce mevcut kayıtları inceleyin. Yinelenen görevler raporu, bildirimi veya başka bir işlemi tekrar çalıştırabilir. Etkiyi anlamadan yeni kayıt eklemeyin veya mevcut olanları topluca silmeyin.