5xx Sunucu Hataları Nasıl İzlenir ve Hızla Çözülür

Bir kullanıcı ödeme sayfasına gelir, “Satın Al” düğmesine basar ve karşısına 502 ya da 504 çıkar. O anda sorun yalnızca bir hata kodu değildir, gelir kaybıdır, güven kaybıdır ve çoğu zaman panikle açılan bir incident kanalının başlangıcıdır.

5xx sunucu hataları, istemcinin değil sistemin sorun yaşadığını söyler. Eğer bu hataları yalnızca loglarda arıyor, tek tek kapatıyor ve kök nedeni sonraya bırakıyorsanız aynı sorun yeniden gelir. Asıl farkı, izleme modelini doğru kurmak yaratır.

Aşağıda pratik bir çerçeve var: hangi metrikleri izlemeniz gerektiği, alarmları nasıl kuracağınız, incident anında ilk neye bakacağınız ve kök nedene göre hangi çözümü uygulayacağınız.

5xx hataları size ne söylüyor?

5xx ailesi, sunucunun isteği işleyemediğini gösterir. Ancak tüm 5xx yanıtları aynı anlama gelmez. 500 çoğu zaman uygulama tarafındaki istisnaları işaret eder. 502 genelde reverse proxy ile upstream servis arasındaki kopukluğu gösterir. 503 kapasite sorunu, bakım modu ya da hazır olmayan servis anlamına gelebilir. 504 ise upstream cevabının zamanında gelmediğini anlatır.

Aşağıdaki tablo, ilk bakışta işinizi hızlandırır:

Kod	Tipik anlam	İlk bakılacak yer
500	Uygulama hatası, beklenmeyen exception	Uygulama logları, son deploy, stack trace
502	Proxy ile upstream arasında iletişim sorunu	Nginx, load balancer, upstream health
503	Aşırı yük, bakım modu, readiness sorunu	CPU, bellek, pod durumu, autoscaling
504	Upstream timeout	Veritabanı, dış API, ağ gecikmesi
507	Yetersiz disk veya geçici depolama	Disk doluluğu, tmp alanı, log büyümesi

Burada asıl hata, kodlara yalnızca “ne oldu” sorusuyla bakmaktır. Doğru soru şudur: “Hangi kullanıcı akışı etkilendi, ne kadar süre etkilendi ve sistem bu sırada ne kadar zorlandı?” Çünkü 5xx oranı tek başına tam resmi vermez. Aynı anda latency artıyorsa, arka planda timeout zinciri çalışıyor olabilir. CPU, bellek, bağlantı havuzu ya da kuyruk derinliği tavana dayanıyorsa, sorun artık saturation, yani kapasite sınırına yaklaşma olabilir.

Bu yüzden SLI ve SLO kavramlarını pratik kurmak gerekir. SLI, ölçtüğünüz hizmet göstergesidir. Örneğin “başarılı HTTP yanıt oranı” ya da “checkout endpoint’inde p95 yanıt süresi”. SLO ise hedefinizdir, mesela 30 gün içinde yüzde 99,9 başarılı istek oranı. Bu hedefin altında kalan pay da error budget olur. 30 günlük yüzde 99,9 hedefte yaklaşık 43,2 dakikalık toleransınız vardır. Eğer 5xx oranı yükselip bu bütçeyi iki saatte yakıyorsa, yeni özellik değil istikrar öncelik kazanır.

İzleme modelini doğru kurun: sayaç değil oran izleyin

Birçok ekip hâlâ “son 5 dakikada 100 tane 500 gördüm” mantığıyla alarm kuruyor. Bu yaklaşım zayıf kalır. Çünkü 100 hata, düşük trafikte felaket olabilir; yüksek trafikteyse küçük bir kıpırdanma olabilir. Bu yüzden 5xx’leri oran üzerinden izleyin.

İyi bir panel, en az şu beş görünümü tek ekranda toplar. İlki toplam istek hacmi ve genel 5xx oranıdır. İkincisi kod bazlı kırılımdır, yani 500, 502, 503 ve 504 ayrı görünmelidir. Üçüncüsü endpoint, servis ve pod bazında dağılımdır. Dördüncüsü p95 ya da p99 latency ile birlikte saturation metrikleridir. Beşincisi ise deploy zaman çizgisi ve bağımlı servis sağlığıdır.

Alarmı hata sayısına göre değil, hata oranına göre kurun. Aksi halde gürültü artar, gerçek incident gözden kaçar.

Bu ekrana trafik kaynağını da eklemek işinizi kolaylaştırır. Mobil uygulama mı etkileniyor, web mi, botlar mı, belli bir ülke mi? Örneğin yalnızca Googlebot isteklerinde 503 artıyorsa, kullanıcılar hissetmeden SEO tarafı zarar görebilir. Böyle durumlarda sunucu logları ile SEO hatalarını bulma yaklaşımı, bot trafiği ile gerçek kullanıcı trafiğini ayırmak için çok işe yarar.

Ayrıca servis haritası faydalıdır. Uygulama, veritabanı, cache, kuyruk, ödeme API’si ve kimlik doğrulama servisi arasında gecikme nerede büyüyor, bunu tek bakışta görmelisiniz. Webalert’ın 5xx oranı alarm rehberi, alarmı toplam sayıya değil orana bağlamanın neden daha temiz sonuç verdiğini iyi özetliyor.

Kısacası iyi izleme, “hata var mı” sorusunu aşar. “Hata ne zaman başladı, hangi rotada yoğunlaştı, neyin ardından geldi ve hangi bağımlılıkla birlikte bozuldu” sorularını aynı anda cevaplar.

Alarm eşiklerini gürültüsüz kurmak

Eşik belirlemek, sayıyı rastgele seçmek değildir. İş mantığı, trafik seviyesi ve servis türü aynı anda düşünülmelidir. Ana sayfa için tolere ettiğiniz oran, ödeme akışı için kabul edilemez olabilir. Aynı şekilde düşük trafikli bir admin panelinde yüzde 2’lik hata oranı birkaç isteğin sonucuyken, checkout servisinde yüzde 0,5 bile ciddidir.

İyi bir başlangıç seti şöyle olabilir:

• Genel 5xx oranı 5 dakika boyunca yüzde 1’i geçerse uyarı üretin.
• Tek bir kritik endpoint’te oran yüzde 5’i geçerse ayrı alarm açın.
• 503 ile birlikte CPU yüzde 85 üstüne çıkarsa kapasite alarmı verin.
• 504 artışıyla upstream p95 latency iki katına çıkarsa timeout alarmı üretin.
• Aynı alarmı göndermeden önce iki ardışık kontrol penceresinde durumu doğrulayın.

Burada önemli nokta, eşikleri tek başına bırakmamaktır. Alarmın içine bağlam ekleyin. Son deploy zamanı, etkilenen rota, etkilenen host sayısı ve son 15 dakikalık trend alarm metninde yer almalı. Böylece on-call kişi grafiğe girmeden ilk resmi görür.

Site24x7’nin HTTP durum trendleri yaklaşımı, tekrar kontrol eden alarm mantığını öne çıkarıyor. Bu mantık iyi çalışır çünkü kısa süreli sıçramalar yüzünden gereksiz gece çağrısı yemezsiniz. Yine de kritik ödeme, giriş veya API gateway gibi servislerde daha sıkı pencereler gerekir.

Alarmı servis seviyesine göre katmanlayın. Bir katman platform sağlığı içindir, örneğin pod restart, düğüm belleği, disk doluluğu. Diğer katman kullanıcı deneyimi içindir, örneğin 5xx oranı ve p95 süre. Üçüncü katman da iş etkisidir, örneğin başarısız ödeme oranı. Bu üç katman aynı anda okunursa sorun daha hızlı izole edilir.

Incident anında ilk 15 dakikada ne yapılmalı?

Incident başladığında amaç teorik analiz değil, etkiyi azaltmak ve yön tayin etmektir. İlk 15 dakika için kısa, uygulanabilir bir kontrol listesi şarttır.

1. Alarmın gerçek olduğunu doğrulayın. Önce genel 5xx oranına, sonra kod kırılımına bakın. Tüm trafik mi etkileniyor, tek endpoint mi?
2. Son deploy zamanını kontrol edin. Hata artışı dağıtımdan hemen sonra başladıysa rollback en hızlı çözümdür.
3. Etki alanını daraltın. Tek bir region, tek bir node, tek bir pod ya da tek bir müşteri segmenti etkileniyor olabilir.
4. Bağımlı servisleri kontrol edin. Veritabanı, Redis, ödeme sağlayıcısı, e-posta servisi ve CDN durum sayfalarına bakın.
5. Saturation metriklerini açın. CPU, bellek, disk, file descriptor, connection pool ve kuyruk derinliği yükselmiş mi?
6. Örnek hataları correlation ID ya da trace ID ile toplayın. Rastgele log okumak yerine aynı isteğin izini sürün.
7. Geçici azaltma adımını seçin. Rollback, trafik azaltma, cache devreye alma, feature flag kapatma ya da bozuk endpoint’i izole etme.

Eğer edge veya CDN katmanı işin içindeyse, Cloudflare 5xx hata rehberi gibi belgelerde önerilen verileri toplamak işinizi hızlandırır. Etkilenen URL’ler, kaynak IP’ler, veri merkezi bilgisi ve örnek istek kimlikleri, “sorun bizde mi upstream’de mi” sorusunu hızla netleştirir.

Bu aşamada iletişim dili de önemlidir. “Sorunu araştırıyoruz” demek yerine, “502 oranı checkout’ta yüzde 7’ye çıktı, son deploy geri alındı, ödeme sağlayıcısı da kontrol ediliyor” gibi somut bilgi verin. Kanal net olursa teknik ekip de daha hızlı hareket eder.

Log, trace ve metrik birlikte okunursa kök neden daha çabuk çıkar

5xx incelemesinde en büyük zaman kaybı, logları bağlamdan kopuk okumaktır. Tek satır hata mesajı çoğu zaman yetmez. Aynı isteğin reverse proxy, uygulama, veritabanı ve dış servis tarafındaki izini birleştirmek gerekir.

Kısa bir örnek:

2026-05-18T10:42:11Z api-3 GET /checkout 504 upstream=payment-api upstream_response_time=30.001 request_time=30.020 trace_id=7fd1

Bu satırın söylediği şey nettir. Uygulama kendi içinde çökmedi. Ödeme servisi 30 saniye içinde cevap vermedi ve istek 504 ile döndü. Böyle bir durumda önce checkout kodunu değil, payment API gecikmesini, ağ yolunu, retry sayısını ve timeout değerlerini incelemek gerekir.

Bir başka örnek:

2026-05-18T10:44:03Z app-2 POST /login 500 exception=NullReferenceError trace_id=9ab2 release=2026.05.18.3

Burada 500 doğrudan uygulama bug’ına işaret eder. Eğer bu satır yeni release etiketiyle birlikte geldiyse, kök neden büyük ihtimalle yanlış deploy ya da eksik migration’dır.

Log yorumlarken şu sırayı izleyin: önce zaman aralığını sabitleyin, sonra hata koduna göre filtreleyin, ardından trace ID ile istek akışını birleştirin. Son aşamada metriklere dönüp aynı anda latency, CPU, pool kullanım oranı ve restart sayısını okuyun. Tracing varsa, en yavaş span genelde soruna yaklaşmanızı sağlar.

SEO etkisini de unutmayın. Googlebot bir süre boyunca 5xx görürse tarama yavaşlayabilir, önemli sayfalar geç ziyaret edilebilir. Bu yüzden kullanıcı trafiği sakin görünse bile bot tarafındaki 5xx kümelerini izlemek faydalıdır. Süre uzarsa Google Search Console indeks sorunlarını çözme yaklaşımıyla tarama ve kapsam sinyallerini kontrol edin.

Kök nedene göre çözüm yolu değişir

Aynı alarmı her seferinde aynı komutlarla çözmeye çalışmak zaman kaybettirir. Soruna göre müdahale değişmelidir.

Uygulama bug’ı ve yanlış deploy

500 artışı son dağıtımdan sonra başladıysa ilk iş diff ve release notlarını kontrol etmektir. Hata yeni endpoint’te mi, eski akışta mı çıktı, bunu ayırın. Feature flag varsa sorunlu özelliği kapatın. Hızlı rollback çoğu zaman en doğru adımdır.

Ayrıca migration ile kod sürümünün uyumuna bakın. Kolon silinmiş, isim değişmiş ya da beklenen config gelmemiş olabilir. Exception log’larında aynı stack trace tekrar ediyorsa kök neden uygulamadadır. Kalıcı çözüm için test senaryosunu incident’e göre genişletin ve deploy öncesi smoke test ekleyin.

Upstream çökmesi, timeout ve bağımlı servis arızaları

502 ve 504’lerde çoğu zaman esas sorun sizin serviste değil, konuştuğunuz başka bir katmandadır. Ödeme, kimlik doğrulama, kargo, e-posta ya da iç servis mesh katmanı cevap veremiyor olabilir. İlk iş upstream sağlığını doğrulamaktır. Timeout süresi çok düşükse sahte 504 üretirsiniz; çok yüksekse thread ve bağlantı havuzunu kilitlersiniz.

Burada üç önlem çok işe yarar: mantıklı timeout değerleri, sınırlı retry ve circuit breaker. Retry sayısı kontrolsüzse küçük sorun büyür. Circuit breaker yoksa bozuk servis tüm trafiği aşağı çeker. Yoğun akışlarda senkron çağrı yerine kuyruk tabanlı desen de 5xx baskısını azaltır.

Kaynak yetersizliği ve saturation

503 gördüğünüzde yalnızca “trafik arttı” demek eksik kalır. CPU yüzde 95’e çıkmış olabilir, bellek baskısı yüzünden pod öldürülüyor olabilir, disk dolduğu için geçici dosya yazılamıyor olabilir. Veritabanı bağlantı sınırı dolduğunda uygulama 500 ya da 503 üretebilir. Nginx worker_connections sınırı, kernel file descriptor limiti ya da container memory limit’i de aynı sonucu doğurur.

Saturation’ı pratik okumak gerekir. İstek sayısı artıyor, latency yükseliyor, ardından 5xx başlıyorsa sistem sınırda çalışıyordur. Kısa vadede autoscaling, pod limit ayarı, cache kullanımı ve pahalı sorguları kesmek işe yarar. Kalıcı tarafta connection pool, query planı, indeks yapısı ve iş kuyruğu tasarımını gözden geçirin.

DNS, ağ, bakım modu ve rate limiting

Bazı 502 ve 503 vakaları uygulama koduyla ilgili değildir. Yanlış DNS kaydı, süresi dolmuş upstream hedefi, ağ bölünmesi, security group kuralı ya da servis keşif sorunu yüzünden proxy arka servise erişemez. Bakım modu yanlış kurgulanırsa kullanıcıya plansız 503 gösterebilirsiniz.

Bir diğer sık neden de rate limiting ayarlarıdır. WAF, API gateway ya da upstream sağlayıcı aşırı istek algılayıp trafiği kesebilir. Bu durumda sadece 5xx oranına değil, 429 ile 5xx ilişkisine de bakın. Eğer bakım planlıysa 503 yanıtına Retry-After ekleyin ve health check rotalarını yanlışlıkla kapatmayın. Ağ kaynaklı olaylarda traceroute yerine önce uygulama katmanındaki DNS çözüm süresini, bağlantı açma süresini ve TLS el sıkışma hatalarını incelemek daha verimlidir.

Tekrarlamayı önlemek için SLO, runbook ve güvenli deploy şart

Sorun çözüldükten sonra “kapanmıştır” demek yetmez. Eğer aynı arıza bir ay içinde tekrar geliyorsa teknik borç birikmiş demektir. Burada SLO yaklaşımı işi disipline eder. Örneğin kritik API için yüzde 99,95 başarı hedefi koyarsınız. Error budget hızlı yanarsa, yeni özellik hızını düşürür, stabilite işlerini öne çekersiniz.

Runbook yazımı da aynı ölçüde önemlidir. İyi bir runbook kısa olur ve net başlar: hangi panel açılacak, hangi sorgu çalıştırılacak, hangi bağımlılık kontrol edilecek, rollback koşulu nedir. On-call kişi sabaha karşı belge okumamalı, yön bulmalıdır.

Güvenli deploy akışı da 5xx riskini düşürür. Canary dağıtım, küçük trafik yüzdesiyle başlama, otomatik rollback, migration uyumluluk kontrolü ve release işaretleri, hatayı yayılmadan yakalar. Kullanıcı akışlarını sentetik testlerle izlemek de faydalıdır. Çünkü health check yeşil olsa bile giriş, sepet ya da ödeme bozuk olabilir.

Burada bir ek not önemli: kalıcı 5xx sorunları sadece uygulama ekibini değil görünürlüğü de etkiler. Arama botları sık sık sunucu hatası görürse crawl verimliliği düşebilir. Bu nedenle teknik SEO ekibiyle SRE ekibinin aynı veri dilini konuşması gerekir. HTTP durum kodları, tarama davranışı ve log analizi aynı masaya geldiğinde sorun daha erken fark edilir.

Sonuç

5xx hatalarını hızlı çözmenin yolu, alarm geldikten sonra kahramanlık yapmak değildir. Güçlü yaklaşım, hata oranını latency ve saturation ile birlikte izlemek, incident anında dar bir kontrol listesi izlemek ve kök nedeni kod, kapasite, ağ ya da bağımlılık düzeyinde ayırmaktır.

En yüksek getiriyi üç adım sağlar: oran bazlı alarm, iz bırakabilen log ve trace yapısı, güvenli deploy akışı. Bunlar kurulduğunda 500 ile 504 aynı sepete girmez; her sinyal sizi doğru kapıya götürür.

Hızlı aksiyon listesi:

• Genel 5xx oranını, kod dağılımını, p95 latency’yi ve saturation metriklerini aynı dashboard’ta toplayın.
• Kritik akışlar için yüzde bazlı alarm kurun, deploy zaman çizgisini ve bağımlı servis durumunu alarm içine ekleyin.
• Runbook’a rollback adımı, örnek log sorgusu, dependency kontrolü ve iletişim şablonunu yazın.

Bunu düzenli yaptığınızda incident’ler tamamen bitmez. Ancak süresi kısalır, etkisi düşer ve ekip her alarmda sıfırdan düşünmek zorunda kalmaz.

This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.