Siteniz gece iki gibi düşer, sabah müşteri arayınca öğrenirsiniz. Uptime izleme tam olarak bu durumu ortadan kaldırmak için vardır, ama kötü kurulmuş bir izleme de ya hiç alarm vermez ya da gereksiz alarmla sizi yorar. Bu rehber wordpress uptime takibini nasıl kuracağınızı, %99, %99,9 ve %99,99 uptime’ın gerçekte kaç dakikalık kesintiye karşılık geldiğini, kontrol aralığının neyi değiştirdiğini ve kesinti anında önce neye bakmanız gerektiğini anlatıyor.
Uptime nedir ve nasıl ölçülür?
Uptime, sitenin belirli bir dönemde erişilebilir olduğu sürenin yüzdesidir. Ölçüm basittir: bir izleyici sitenize düzenli aralıklarla istek gönderir, yanıt başarılıysa o aralığı ‘yukarıda’, değilse ‘aşağıda’ sayar. Yüzde, yukarıda geçen sürenin toplam süreye oranıdır.
İki önemli sonuç çıkar. Birincisi, uptime yüzdesi yalnızca ölçüm yönteminiz kadar doğrudur. İkincisi, yüzde tek başına bir karar vermez: yılda dört kez beş dakikalık kesinti ile tek bir yirmi dakikalık kesinti aynı yüzdeyi verebilir, ama etkileri farklıdır.
Neden sadece ana sayfanın açıldığını kontrol etmek yetmez?
Ana sayfanın açılması, sitenin sağlıklı olduğunu garanti etmez. Önbellek eklentisi ya da CDN, PHP veya veritabanı çökmüşken bile önceden saklanmış sayfayı sunmaya devam edebilir. Siz tarayıcıdan bakınca her şey normal görünür, oysa giriş yapamaz, sipariş veremez ya da form gönderemezsiniz.
Doğru bir kontrol şunları ayırt eder:
- Gerçek HTTP isteği: izleyici yalnızca sunucuya ping atmaz, sayfayı tarayıcı gibi ister ve durum kodunu (200, 500, 503 gibi) okur.
- Önbelleği aşan kontrol: bazı sayfalar önbelleğe girmez (örneğin sepet, giriş ya da bir sorgu parametresi eklenmiş adres). Önbelleğin arkasındaki durumu böyle ölçebilirsiniz.
- İçerik doğrulaması: 200 dönen bir hata sayfası da olabilir. Sayfada beklenen bir metnin geçip geçmediğini kontrol eden izleyiciler bu durumu yakalar.
- Birden fazla adres: ana sayfa kadar kritik bir iç sayfayı da (ödeme, iletişim) izlemek anlamlıdır.
WordPress’te hangi adresleri izlemeliyim?
Her sitenin kritik yolları farklıdır, ama genel bir başlangıç şudur: ana sayfa, giriş sayfası (/wp-login.php), bir yazı ya da ürün sayfası ve sipariş ya da iletişim gibi iş akışını taşıyan bir sayfa. REST API de bir sinyaldir: varsayılan olarak /wp-json/ adresi JSON döner, ama güvenlik eklentileri bunu kapatmış olabilir. Böyle bir durumda kapalı olması hata değil, yapılandırmadır, izleyiciyi buna göre ayarlayın.
Uptime izleme sayfaların açılıp açılmadığına bakar. Site içindeki linklerin kırık olup olmadığı ayrı bir kontroldür, bunun için kırık link düzeltme rehberine bakın.
Sunucu içinden değil dışarıdan izleyin
Sunucunun kendi içinden çalışan izleme, sunucu tamamen kapandığında kendisi de kapanır ve size haber veremez. Bu yüzden izleme, sitenizden bağımsız bir yerden çalışmalı. Aksi hâlde ‘kesinti oldu ama alarm gelmedi’ durumuyla karşılaşırsınız.
%99, %99,9 ve %99,99 uptime kaç dakikalık kesinti demektir?
Aşağıdaki tablo, bir aylık (30 gün = 43.200 dakika) ve bir yıllık (365 gün = 525.600 dakika) dönemde, her uptime yüzdesinin izin verdiği azami kesinti süresini gösteriyor. Hesap şudur: toplam dakika, kesinti yüzdesiyle çarpılır (%99 için yüzde 1).
| Uptime | Aylık azami kesinti | Yıllık azami kesinti |
|---|---|---|
| %99 | 432 dakika (7 saat 12 dakika) | 5.256 dakika (87,6 saat, yaklaşık 3,65 gün) |
| %99,5 | 216 dakika (3 saat 36 dakika) | 2.628 dakika (43,8 saat) |
| %99,9 | 43,2 dakika | 525,6 dakika (8,76 saat) |
| %99,95 | 21,6 dakika | 262,8 dakika (4,38 saat) |
| %99,99 | 4,32 dakika (yaklaşık 4 dakika 19 saniye) | 52,56 dakika |
Bu rakamlar ölçüm hassasiyetinin de sınırını gösterir: aylık 4 dakikalık bir kesintiyi yakalamak için kontrol aralığının bundan çok daha kısa olması gerekir. Ayrıca bir hosting firmasının ‘%99,9 garanti’ vaadi, çoğunlukla planlı bakımı ve kendi tanımladığı kesinti çeşitlerini dışarıda bırakır. Vaadin ayrıntısını sözleşmeden okuyun.
Kendi uptime hesabınızı yapın
Tablodaki değerleri kendi dönemine uyarlamak kolaydır. Formül, toplam dakikayı kesinti oranıyla çarpmaktır. Örneğin 90 günlük bir çeyrekte %99,9 hedefi için izin verilen kesinti, 90 gün çarpı 24 saat çarpı 60 dakika çarpı 0,001 hesabıyla yaklaşık 129,6 dakikadır. Tersinden de hesaplayabilirsiniz: bir ayda toplam 30 dakika kesinti yaşandıysa uptime, 1 eksi 30 bölü 43.200, yani yaklaşık yüzde 99,93 olur.
kesinti_dakikasi = toplam_dakika x (1 - uptime_orani)
uptime_orani = 1 - (kesinti_dakikasi / toplam_dakika)Bu rakamlar, bir hosting vaadini ya da müşteriye verdiğiniz bir hizmet seviyesi taahhüdünü sınamak için de kullanışlıdır. Bir taahhüt vermeden önce kendi ölçümünüzle geçmiş birkaç ayı hesaplayın ve gerçekçi olup olmadığına bakın.
Kontrol aralığı neyi değiştirir?
Kontrol aralığı, bir kesintinin ne kadar sürede fark edileceğini ve kısa kesintilerin yakalanıp yakalanmayacağını belirler. Aralık 30 dakikaysa, 10 dakikalık bir kesinti iki kontrol arasında kalıp hiç görünmeyebilir. Aralık 5 dakikaysa, 5 dakikadan kısa kesintiler aynı şekilde kaçabilir.
| Kontrol aralığı | Kesintiyi fark etme gecikmesi (en kötü durum) | Kısa kesintiler |
|---|---|---|
| 30 dakika | Yaklaşık 30 dakika (doğrulama için ikinci kontrol bekleniyorsa daha fazla) | 10-20 dakikalık kesintiler kaçabilir |
| 5 dakika | Yaklaşık 5 dakika (ikinci kontrolle onay ile 10 dakikaya kadar) | 5 dakikadan kısa kesintiler kaçabilir |
| 1 dakika | Yaklaşık 1-2 dakika | Çok kısa kesintiler yine görünmeyebilir |
Hobi blogu ya da küçük bir kurumsal site için 30 dakika çoğu zaman yeterli olur. Sipariş alan bir mağaza ya da müşteriye hizmet veren bir site için 5 dakika ya da daha kısa bir aralık mantıklıdır. Her şeyi çok sık sorgulamak da sunucuya yük bindirir, ‘en kısa’ aralığı seçmek yerine ihtiyacınıza uygun olanı seçin.
Yanıt süresi trendleri neden önemli?
Site tamamen düşmeden önce genellikle yavaşlar. Yanıt süresi (isteğin gönderilmesinden yanıtın gelmesine kadar geçen süre) haftalar içinde artıyorsa bunun ardında dolan bir veritabanı, kaynak yetersizliği, yavaş bir eklenti ya da trafik artışı olabilir. Tek bir yanıt süresi değeri bilgi vermez, trend verir.
- Ani sıçrama: yeni bir eklenti, güncelleme ya da dışarıdan gelen bir yük (bot trafiği) olabilir.
- Yavaş yavaş artış: veritabanı büyüyor, önbellek etkisini yitiriyor ya da hosting kaynağı yetmiyor olabilir.
- Belirli saatlerde yavaşlama: zamanlanmış görevler (yedek, tarama) ya da paylaşımlı sunucu komşuları olabilir.
Yavaşlığın nedenini ararken WordPress hızlandırma ipuçları yazısı sıradaki adımı gösterir.
Yanlış alarmı azaltmak için uyarı eşiklerini nasıl ayarlarım?
Her başarısız isteğe alarm vermek, kısa sürede alarmları görmezden gelmenize yol açar. Tek bir ağ dalgalanması, izleyicinin kendi bağlantı sorunu ya da bir saniyelik yoğunluk, gerçek bir kesinti değildir. Yanlış alarmı azaltmanın pratik yolları şunlardır:
- 1Ardışık başarısızlık sayısı bekleyin: örneğin art arda iki ya da üç kontrol başarısız olunca alarm verin. Tek seferlik hatayı sessizce geçin.
- 2Başarısızlığı ikinci bir kontrol noktasından teyit ettirin. İzleyici kendi tarafında sorun yaşıyorsa bu yanlış alarmı keser.
- 3Yanıt süresi için tek bir yavaş isteği değil, belirli bir süre boyunca yüksek kalan ortalamayı eşik alın.
- 4Planlı bakım penceresinde alarmı susturun, böylece bilinen bir kesinti alarm yorgunluğu yaratmaz.
- 5Alarmı kritik (site tamamen kapalı) ve bilgi (yavaşlıyor) olarak ayırın, her ikisini aynı kanaldan aynı acillikle göndermeyin.
Hangi bildirim kanallarını kullanmalıyım?
Bildirimin kime gideceği de kanal kadar önemlidir: kesinti anında bakabilecek kişiyi belirleyin ve nöbet düzeni varsa onu yazın.
Uyarı, sizin gerçekten göreceğiniz yere gitmelidir. E-posta kolaydır ama gece görülmeyebilir. Telefona gelen bir anlık bildirim ya da bir sohbet kanalı (Slack, Teams gibi) daha hızlı fark edilir. Ekip içinde çalışıyorsanız tek kişinin e-postasına bağımlı kalmayın, ortak bir kanal ya da yedek alıcı tanımlayın. Kritik kesintiler için birincil ve yedek kanal olması iyi bir alışkanlıktır.
Site kapalıysa ilk ne yapmalıyım?
Sakin kalıp sıralı ilerlemek, rastgele denemekten çok daha hızlıdır. Aşağıdaki sıra, en olası ve en ucuz kontrolden başlar.
- 1Sorunun sizde olmadığını doğrulayın: başka bir cihaz ve ağdan, gizli pencerede açın. Başka bir izleme noktasından da bakın.
- 2Hata türüne bakın: 500 uygulama hatası, 502/503/504 sunucu tarafı sorun, SSL uyarısı sertifika sorunudur. Sertifika uyarısı için sertifika rehberine bakın.
- 3Hosting sağlayıcınızın durum sayfasına ve e-postalarına bakın. Sunucu genelinde bir sorun olabilir.
- 4Son değişikliği düşünün: yakın zamanda bir eklenti ya da tema güncellediyseniz önce onu geri alın.
- 5Hata günlüğüne bakın. Sunucunun hata günlüğü ya da WordPress hata ayıklama günlüğü nedeni gösterir.
- 6Kaynak sorunu varsa (bellek, CPU, disk dolu) hosting planınızı ya da kaynak kullanımınızı gözden geçirin.
- 7Çözülemiyorsa son sağlam yedeğe dönmeyi düşünün.
Beyaz ekran ya da kritik hata mesajı görüyorsanız WordPress kritik hata rehberi ilk elden adımları verir, güncelleme sonrası bozulduysa güncelleme sonrası site bozuldu yazısına bakın. Yedeğe dönecekseniz yedek geri yükleme adımları hazır dursun. Sertifika uyarısı varsa SSL sertifikası süresi doldu yazısı ilk durak olur.
Sertifika uyarısı alıyorsanız, SSL sertifika sürelerinin kısalmasıyla yenilemelerin daha sık yapılması gerektiğini ve sessizce başarısız olan yenilemelerin bu tür uyarıların sık nedeni olduğunu unutmayın.
# Sunucudan kendi sitenizin durum kodunu hızlıca görün
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://alanadiniz.com/Yukarıdaki komut, durum kodunu ve toplam yanıt süresini yazar. Hızlı bir elle kontrol için işe yarar ve bir izleyicinin gördüğünü doğrulamanızı sağlar.
Sık sorulan sorular
Kesintiden sonra ne kaydetmeliyim?
Her kesintiyi kısa bir kayda bağlayın: başlangıç ve bitiş saati, belirti, kök neden ve ne yapıldığı. Üç ay sonra tekrar eden bir örüntü (örneğin her ay aynı gün yaşanan yavaşlama, her güncellemeden sonra gelen hata) bu kayıtlardan çıkar. Müşteriye ya da yöneticinize rapor verirken de elinizde somut bir süre ve neden olur.
Uptime yüzdesi sözleşmede garanti edilen değerin altına düşerse ne yapmalıyım?
Önce kendi ölçümünüzü, ardından hosting firmasının kayıtlarını ve sözleşmedeki kesinti tanımını karşılaştırın. Hosting vaatlerinde genellikle planlı bakım ve bazı dış etkenler kapsam dışı bırakılır. Tazminat ya da kredi talebi için hosting firmasının belirlediği süre içinde yazılı başvurmanız gerekebilir. Bağımsız bir izleyicinin kaydı bu konuşmada somut bir dayanaktır.
Ücretsiz uptime izleme yeterli mi?
Küçük siteler için ücretsiz bir izleyici çoğu zaman yeterlidir. Dikkat edilecek şeyler kontrol aralığı, doğrulama (ikinci kontrol) ve bildirim kanallarıdır. Ücretsiz çözümlerde aralık genellikle daha uzundur, ihtiyacınız buna uyuyor mu diye bakın.
%99,9 uptime iyi bir hedef mi?
Aylık yaklaşık 43 dakikalık kesintiye karşılık gelir. Çoğu küçük ve orta ölçekli site için gerçekçi ve iyi bir hedeftir. Hedefi sözleşmedeki taahhüde değil, kendi ölçümünüze göre değerlendirin.
Site açılıyor ama yavaş, bu uptime’ı etkiler mi?
Çoğu izleyici yalnızca yanıt gelip gelmediğine bakar. Yavaşlık uptime’ı düşürmeyebilir ama kullanıcıyı kaçırır. Bu yüzden yanıt süresi trendini de izlemek gerekir.
Planlı bakımı kesinti saymalı mıyım?
Kendi raporlamanızda ayrı tutabilirsiniz, ama ziyaretçi açısından site yine kapalıdır. Planlı bakımda alarmı susturun, kaydı ise ayrı işaretleyin.
Kesintiyi siz değil, panel fark etsin
Watch Your WP, sitelerinize gerçek HTTP isteğiyle uptime izleme yapar: her site 10 dakikada bir, ücretsiz olarak kontrol edilir. Kesinti geçmişi, uptime yüzdesi ve yanıt süresi trendleri panelde durur.

Erdinç
Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.
LinkedIn
