Hosting Error Log Dosyası Nasıl Okunur?

özgür BAYRAM28 Haziran 2026, 21:00

0 96 7 dakika okuma süresi

Hosting error log, web sunucusunun veya PHP’nin karşılaştığı hata ve uyarıları zaman damgasıyla kaydeden dosyadır. Sitenizde beyaz ekran, 500 Internal Server Error, yavaşlama veya çalışmayan bir form gibi bir sorun olduğunda gerçeğe en hızlı ulaşacağınız yer çoğu zaman bu kayıtlardır. Ancak bir log satırı tek başına kök nedeni göstermeyebilir; hatanın zamanı, istenen URL ve uygulamada yapılan işlemle eşleştirilmesi gerekir. Bu rehberde farklı hosting ortamlarında hata kayıtlarının nerede bulunduğunu, bir log satırının nasıl okunacağını, en sık görülen hata mesajlarının ne anlama geldiğini ve düzeltmenin nasıl doğrulanacağını adım adım ele alıyoruz.

Table of Contents

Hangi log, hangi soruyu cevaplar?

“Error log” tek bir dosya değildir. Bir web isteği birden fazla katmandan geçer ve her katman kendi kaydını tutar. Doğru dosyaya bakmak, teşhis süresini büyük ölçüde kısaltır.

Web sunucusu hata kaydı (Apache / LiteSpeed / Nginx): İzin hataları, yapılandırma sorunları, zaman aşımları ve PHP sürecine ulaşılamaması gibi sunucu düzeyindeki sorunları kaydeder.
PHP hata kaydı: Fatal error, warning ve notice gibi PHP kodundan kaynaklanan hataları içerir. Beyaz ekran ve 500 hatalarının çoğu burada açıklanır.
Uygulama kaydı: WordPress’in debug.log dosyası veya Laravel’in storage/logs klasöründeki kayıtlar, uygulamanın kendi ürettiği ayrıntılı mesajları içerir.
Erişim kaydı (access log): Hata kaydı değildir ama her isteğin zamanını, URL’sini, durum kodunu ve kaynağını gösterdiği için hatanın hangi istekle ilişkili olduğunu bulmada çok değerlidir.

Hangi log hangi soruyu cevaplar? — Bir istek birden fazla katmandan geçer; her katman kendi kaydını tutar.

Logu bulmak: ortama göre konumlar

cPanel kullanan paylaşımlı hosting

cPanel’de Metrics → Errors ekranı, hesabınıza ait son web sunucusu hatalarını gösterir. Bu ekran hızlı bir başlangıç noktasıdır; ancak yalnızca son kayıtları listeler ve PHP hatalarının tamamını içermeyebilir.

PHP hata dosyası, sağlayıcının yapılandırmasına göre farklı yerde olabilir. Birçok cPanel kurulumunda PHP, hatayı üreten betiğin bulunduğu klasörde error_log adlı bir dosya oluşturur; örneğin WordPress’in kök dizininde veya wp-admin klasöründe bu dosyayı görebilirsiniz. MultiPHP INI Editor üzerinden log_errors ayarının açık olduğunu ve error_log yolunu kontrol edebilirsiniz. Canlı sitede display_errors ayarı kapalı olmalıdır; hataları ziyaretçiye göstermek dosya yollarını ve veritabanı bilgilerini açığa çıkarabilir.

VPS ve özel sunucular

Kendi sunucunuzu yönetiyorsanız kayıtlar genellikle şu konumlarda bulunur (dağıtıma ve yapılandırmaya göre değişebilir):

Nginx: /var/log/nginx/error.log
Apache (Debian/Ubuntu): /var/log/apache2/error.log
Apache (RHEL/AlmaLinux): /var/log/httpd/error_log
PHP-FPM: /var/log/php*-fpm.log veya havuz yapılandırmasında tanımlı dosya

Sanal sunucu (virtual host) yapılandırmasında site bazında ayrı bir hata kaydı tanımlanmış olabilir; birden fazla site barındırıyorsanız önce ilgili sitenin yapılandırmasındaki error_log satırına bakın.

WordPress ve Laravel

WordPress’te ayrıntılı hata kaydı için wp-config.php dosyasında WP_DEBUG ve WP_DEBUG_LOG sabitleri true, WP_DEBUG_DISPLAY ise false yapılır. Kayıtlar varsayılan olarak wp-content/debug.log dosyasına yazılır. Bu dosya web üzerinden erişilebilir bir konumda olduğu için sorunu çözdükten sonra hata ayıklamayı kapatın veya kaydı web kök dizini dışındaki bir yola yönlendirin. Laravel’de ise kayıtlar storage/logs/laravel.log dosyasında tutulur; ayrıntılar için Laravel log dosyaları rehberimize bakabilirsiniz.

Bir log satırı nasıl okunur?

Önce olay zamanını ve HTTP durumunu belirleyin; ardından o zaman aralığındaki ilgili hata satırını arayın. Tipik bir PHP fatal error satırı şöyle görünür:

[09-Oct-2026 14:32:07 Europe/Istanbul] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/kullanici/public_html/wp-content/plugins/ornek-eklenti/includes/rapor.php on line 214

Bu satırı parçalara ayırdığımızda:

Zaman damgası: Hatanın ne zaman oluştuğu. Sorunun yaşandığı anla eşleşiyor mu? Saat dilimine dikkat edin; sunucu UTC kullanıyor olabilir.
Seviye: Fatal error betiğin durduğunu, Warning ve Notice ise çalışmanın devam ettiğini gösterir. Beyaz ekranın sebebi neredeyse her zaman bir fatal error’dır.
Mesaj: Ne olduğunu söyler; bu örnekte PHP’ye ayrılan 256 MB bellek dolmuş.
Dosya ve satır: Hatanın nerede tetiklendiğini gösterir. Yol, sorunun hangi eklenti veya temadan geldiğini çoğu zaman doğrudan söyler.

Dosya ve satır, hatanın tetiklendiği yeri gösterir; nedeninin bulunduğu yeri değil. Bellek hatası rapor dosyasında ortaya çıkmış olabilir, ancak asıl neden başka bir eklentinin belleği önceden doldurması da olabilir. Bu nedenle aynı zaman aralığındaki diğer uyarılara ve hatanın hangi sayfada tekrarlandığına da bakın.

Komut satırında hızlı inceleme

SSH erişiminiz varsa büyük log dosyalarını açmaya çalışmak yerine şu komutlar işinizi kolaylaştırır:

# Son 100 satır
tail -n 100 error_log

# Canlı izleme: sorunu tarayıcıda tekrarlarken yeni satırları görün
tail -f error_log

# Yalnızca fatal error satırları
grep "PHP Fatal" error_log | tail -n 20

# En sık tekrarlanan hata mesajları
grep -o "PHP [A-Za-z ]*:.*" error_log | sort | uniq -c | sort -rn | head

tail -f ile kaydı izlerken sorunlu sayfayı tarayıcıda yenilemek, hatayı istekle birebir eşleştirmenin en pratik yoludur.

En sık görülen hata mesajları ve anlamları

404, 500, PHP fatal error ve zaman aşımı farklı sorunlardır. Aşağıdaki mesajlar, paylaşımlı hosting ve VPS ortamlarında en sık karşılaşılanlardır.

En sık görülen log mesajları ve ilk kontrol — Dosya ve satır hatanın tetiklendiği yeri gösterir; nedeni her zaman orada değildir.

Allowed memory size exhausted: PHP’ye ayrılan bellek sınırı doldu. Sınırı artırmak geçici bir çözümdür; asıl soru hangi işlemin bu kadar bellek kullandığıdır. Büyük dışa aktarma, görsel işleme veya hatalı bir döngü sık nedenlerdir.
Maximum execution time exceeded: Betik izin verilen çalışma süresini aştı. Uzun süren işlemleri parçalara bölün veya arka planda çalıştırın.
Permission denied: PHP veya web sunucusu bir dosyayı okuyamıyor ya da yazamıyor. Dosya sahibi ve izinleri inceleyin; ayrıntılar için dosya izinleri rehberine bakın. Sorunu 777 izni vererek “çözmeye” çalışmayın.
Call to undefined function: Çağrılan fonksiyon tanımlı değil. Genellikle eksik bir PHP eklentisi (ör. mbstring, intl), PHP sürümü uyumsuzluğu veya bir eklentinin devre dışı kalmasıyla ilgilidir.
Class not found: Bir sınıf yüklenemedi. Composer bağımlılıklarının yüklenmediği veya otomatik yükleyicinin güncellenmediği durumlarda görülür.
End of script output before headers: Apache’nin PHP betiğinden beklediği yanıtı alamadığını gösterir; çoğu zaman 500 hatasıyla birlikte görülür ve izin, sahiplik veya kaynak sınırı sorunlarına işaret eder.
upstream timed out (Nginx): Nginx, PHP-FPM’den zamanında yanıt alamadı; kullanıcı 504 Gateway Timeout görür. Yavaş sorgular, dış API çağrıları veya yetersiz PHP işçi sayısı sık nedenlerdir.
client denied by server configuration: Sunucu yapılandırması (ör. .htaccess kuralı) isteği engelliyor. Yeni eklenen bir güvenlik kuralı meşru istekleri de engelliyor olabilir.

Uyarı (warning) ve bildirim (notice) seviyesindeki mesajlar siteyi durdurmaz; ancak çok sık tekrarlanıyorsa log dosyasını hızla büyütür ve gerçek hataları bulmayı zorlaştırır. Bu mesajları da düzenli olarak gözden geçirip kaynağındaki eklenti veya tema geliştiricisine bildirin.

Teşhis sırası: rastgele değil, sistemli ilerleyin

Belirtiyi tanımlayın: Hangi sayfa, hangi işlem, hangi saatte? Tüm site mi etkileniyor, tek bir sayfa mı?
Durum kodunu öğrenin: Tarayıcının geliştirici araçlarında veya curl -I ile sayfanın döndürdüğü kodu görün.
Zamanla eşleştirin: Erişim kaydında o isteği bulun, aynı saniyedeki hata kaydı satırlarına bakın.
Son değişikliği hatırlayın: Eklenti, tema veya PHP sürümü güncellemesi, yeni bir kod dağıtımı ya da sunucu ayarı değişikliği yapıldı mı?
Hipotezi test edin: Şüphelendiğiniz eklentiyi test ortamında devre dışı bırakın veya önceki sürüme dönün.

Gizli dosya yollarını, veritabanı bilgilerini ve kullanıcı verisini kamuya açık forumlara veya destek mesajlarına kopyalamayın. Log satırını paylaşmanız gerekiyorsa kullanıcı adınızı, alan adınızı ve kişisel bilgileri maskeleyin.

Örnek vaka: güncelleme sonrası beyaz ekran

Gerçekçi bir senaryo üzerinden ilerleyelim. Bir WordPress sitesinde gece otomatik eklenti güncellemeleri çalışıyor ve sabah site yöneticisi ana sayfanın açıldığını, ancak yönetim panelinin beyaz ekran verdiğini fark ediyor.

Durum kodu: curl -I ile /wp-admin/ adresi kontrol edildiğinde 500 döndüğü görülüyor.
Doğru dosya: cPanel Errors ekranında yalnızca genel bir satır var; wp-admin klasöründeki error_log dosyası ise daha ayrıntılı.
Log satırı: Kayıtta PHP Fatal error: Uncaught Error: Call to undefined method mesajı ve bir form eklentisinin dosya yolu görülüyor. Zaman damgası, otomatik güncellemenin çalıştığı saatten birkaç dakika sonrası.
Hipotez: Güncellenen form eklentisi, henüz güncellenmemiş bir eklenti eklentisiyle (add-on) uyumsuz hale gelmiş.
Test: SFTP ile eklentinin eklenti klasörünün adı geçici olarak değiştirilerek devre dışı bırakılıyor. Yönetim paneli açılıyor ve log’a yeni fatal error yazılmıyor.
Kalıcı çözüm: Ek paket güncelleniyor, klasör adı geri alınıyor, panel ve form gönderimi yeniden test ediliyor.

Bu süreçte rastgele eklentileri kapatmak veya PHP sürümünü değiştirmek yerine log satırının gösterdiği dosya yolundan ilerlemek, sorunu dakikalar içinde çözmeyi sağlıyor. Ayrıca otomatik güncellemelerden sonra kısa bir kontrol yapmak veya kritik eklentileri önce test ortamında güncellemek, aynı sorunun tekrar yaşanmasını önler.

Yavaşlık ve zaman aşımı sorunlarında loglar

Hata kayıtları yalnızca çöken sayfalar için değil, yavaşlık sorunlarında da ipucu verir. Nginx’te upstream timed out, PHP-FPM’de server reached pm.max_children setting veya Apache’de sık tekrarlanan zaman aşımı mesajları, sunucunun gelen istekleri karşılamakta zorlandığını gösterir.

PHP işçi sınırı: PHP-FPM kaydında maksimum işçi sayısına ulaşıldığı uyarısı, eşzamanlı isteklerin kuyrukta beklediği anlamına gelir. İşçi sayısını artırmadan önce sunucunun belleğinin buna yetip yetmediğini hesaplayın.
Yavaş betik kaydı: PHP-FPM’in slowlog özelliği, belirli bir süreyi aşan isteklerin hangi fonksiyonda beklediğini kaydeder. Yavaş sorgu veya dış API çağrısı yapan eklentiyi bulmada çok etkilidir.
Veritabanı kayıtları: MySQL yavaş sorgu kaydı açıksa, uzun süren sorgular ayrıca listelenir.
Bot trafiği: Erişim kaydında aynı IP’den saniyede çok sayıda istek veya giriş sayfasına yoğun deneme görüyorsanız yavaşlığın kaynağı kötü niyetli trafik olabilir.

Paylaşımlı hostingde bu ayrıntılı kayıtlara erişiminiz olmayabilir. Bu durumda hosting firmasının kaynak kullanım grafiklerini (CPU, bellek, giriş işlemi sayısı) hata zamanlarıyla karşılaştırmak, sınırlara takılıp takılmadığınızı anlamanıza yardımcı olur.

Düzeltmeyi doğrulama

Hatanın tekrar üretilebildiği URL’yi mümkünse test ortamında açın. Eklenti veya tema güncellemesiyle ilişkiliyse önce geri dönüş olanağını hazırlayın: tam yedek alın veya önceki sürümün dosyalarını saklayın. Değişiklikten sonra aynı işlemi tekrarlayıp yeni log kaydını ve kullanıcıya dönen sonucu kontrol edin. Hata kaydında aynı mesajın tekrar oluşmaması, sorunun gerçekten çözüldüğünün en net kanıtıdır.

Düzeltmeden sonra birkaç gün boyunca kaydı izlemeye devam edin. Bazı hatalar yalnızca belirli saatlerde çalışan zamanlanmış görevlerde, yoğun trafik anlarında veya belirli kullanıcı işlemlerinde ortaya çıkar.

Log dosyalarını yönetmek

Hata kayıtları zamanla büyür ve paylaşımlı hostingde disk kotanızı doldurabilir. Birkaç gigabaytlık bir error_log dosyası, aynı uyarının saniyede onlarca kez yazıldığının işaretidir. Dosyayı silmek yerine önce en sık tekrarlanan mesajı bulup kaynağını düzeltin; ardından eski kaydı arşivleyin veya temizleyin.

VPS’te logrotate ile kayıtları düzenli olarak döndürün ve sıkıştırın.
Hata kayıtlarının web üzerinden erişilebilir olmadığından emin olun; kök dizindeki error_log ve debug.log dosyalarına erişimi sunucu kuralıyla engelleyin.
Önemli hatalar için e-posta veya mesajlaşma uygulaması üzerinden bildirim gönderen basit bir izleme kurun; sorunları kullanıcılardan önce siz fark edin.

Sıkça Sorulan Sorular

cPanel’de error_log dosyasını göremiyorum, neden?

Dosya yalnızca bir hata oluştuğunda yaratılır; hiç hata yoksa bulunmayabilir. Ayrıca gizli dosyalar Dosya Yöneticisi’nde gösterilmiyor olabilir veya sağlayıcınız kayıtları farklı bir dizinde tutuyor olabilir. MultiPHP INI Editor’da error_log ayarını kontrol edin.

WP_DEBUG’ı canlı sitede açık bırakmak sorun olur mu?

Hataları ekranda göstermek (WP_DEBUG_DISPLAY) ziyaretçilere dosya yollarını ve teknik bilgileri gösterir; canlı sitede kapalı olmalıdır. Yalnızca dosyaya kaydetme kısa süreli teşhis için kullanılabilir, ancak kayıt dosyasının herkese açık olmadığından emin olun.

Log dosyasını silmek güvenli mi?

Log dosyasını silmek siteyi bozmaz; ancak sorunun izini de kaybettirir. Önce tekrarlayan hataların kaynağını düzeltin, gerekiyorsa kaydın bir kopyasını alın, sonra temizleyin.

500 hatası var ama log boş, ne yapmalıyım?

PHP hata kaydının kapalı olması, hatanın web sunucusu düzeyinde oluşması veya yanlış dosyaya bakıyor olmanız mümkündür. Hem web sunucusu hem PHP kaydını kontrol edin; .htaccess dosyasındaki hatalı bir satır da log oluşturmadan 500 hatasına yol açabilir. Ayrıntılar için 500 Internal Server Error rehberimize bakın.

Hata kaydında saat neden farklı görünüyor?

Sunucular çoğu zaman UTC saat dilimini kullanır; Türkiye saati ise UTC+3’tür. Sorunun yaşandığı anı log satırıyla eşleştirirken bu farkı hesaba katın. PHP’nin date.timezone ayarı ile web sunucusunun kendi saat dilimi farklı olabileceği için aynı olay iki farklı dosyada farklı saatlerle görünebilir.

Paylaşımlı hostingde loglara erişimim yoksa ne yapabilirim?

cPanel Errors ekranı, MultiPHP INI Editor ile açılabilen PHP hata kaydı ve WordPress’in debug.log dosyası çoğu sorun için yeterli bilgiyi verir. Daha ayrıntılı kayıtlara ihtiyaç duyarsanız hosting firmasının destek ekibinden, sorunun yaşandığı zaman aralığını belirterek ilgili kayıt satırlarını isteyebilirsiniz.