Kendi Status Page’inizi Kurun: Uptime Kuma ile Uptime İzleme ve Kesinti İletişimi

Altyapı planlama, kapasite analizi veya SLA hedefleri üzerine yaptığınız her toplantıda aynı konuya dönülür: Kullanıcıya ne kadar süre kesintisiz hizmet verebiliyoruz ve bunu ne kadar şeffaf gösterebiliyoruz? Sadece iç tarafta log ve izleme panelleri kurmak artık yeterli değil; müşteriye açık, okunabilir ve güncel bir status page (durum sayfası) olmadan güven inşa etmek zor. Üstelik bir kesinti yaşandığında, hem teknik ekibin iç koordinasyonunu hem de müşteri iletişimini aynı yerden yönetmek büyük avantaj sağlıyor.

Bu yazıda, Uptime Kuma gibi self-hosted (kendi kendinize barındırdığınız) araçları kullanarak kendi status page’inizi nasıl kurabileceğinizi adım adım anlatacağız. Hangi mimariyi tercih etmeniz gerektiğinden, Uptime Kuma kurulumuna, monitor (izleme) tasarımından kesinti iletişimi pratiklerine kadar tüm süreci DCHost ekibesinde sahada gördüğümüz örneklerle ele alacağız. Eğer hâlihazırda uptime izleme araçları kullanıyor ancak bunları müşteriye yansıtacak şık bir status page’iniz yoksa, bu rehberi bitirdiğinizde net bir yol haritasına sahip olacaksınız.

Neden Kendi Status Page’iniz Olmalı?

Status page, temel olarak kullanıcılarınıza ve ekibinize; servislerinizin çalışır durumda mı, kısmi sorun mu yaşıyor, bakım mı var gibi durumları gerçek zamanlı gösteren herkese açık bir pano sağlar. Birçok projede loglar, grafikler, alarmlar zaten vardır; ancak bunlar genellikle sadece teknik ekibin erişebileceği karmaşık panellerdedir. Status page ise bu veriyi sadeleştirip son kullanıcıya uygun bir dille sunar.

Kendi status page’inizi kurmanın size sağladığı başlıca faydalar:

• Güven ve şeffaflık: Müşteri, kesinti olduğunda nedenini ve güncellemeleri takip edebildiği için daha az kaygı yaşar.
• Destek yükünü azaltma: Herkesin aynı anda aynı soruyu sorduğu yoğun destek dönemlerinde, tek bir URL üzerinden durumu anlatabilirsiniz.
• SLA takibi: Söz verdiğiniz uptime oranlarını gerçekte ne kadar sağladığınızı ölçmek ve raporlamak kolaylaşır.
• İç koordinasyon: Teknik ve iş birimleri, tek bir referans noktasından o anki servis durumunu görebilir.

Uptime ve SLA kavramlarını daha sayısal bir bakışla ele almak isterseniz, hazırladığımız 99.9% uptime ve SLA sözleşmelerini okuma rehberi de bu yazıyı güzel tamamlayacaktır.

Status Page Mimarisi: Hangi Bileşenlerden Oluşur?

Sağlam bir status page sadece güzel görünen bir HTML sayfa değildir; arkasında düzenli veri toplayan ve bunu anlamlı hale getiren bir mimari bulunur. Tipik bir kurulumda şu bileşenler yer alır:

• İzleme katmanı (monitoring): HTTP(S), ping, TCP port, DNS, SSL sertifika süresi gibi metrikleri düzenli aralıklarla kontrol eden ajanlar.
• Status page uygulaması: Uptime Kuma gibi; monitor sonuçlarını kaydeden, statüleri hesaplayan ve herkese açık bir web arayüzü sunan yazılım.
• Bildirim kanalları: E-posta, Telegram, Slack benzeri araçlar, webhook’lar; kesinti olduğunda ekibi uyarmak için.
• Veritabanı ve saklama katmanı: Tarihsel veriyi saklayıp son 24 saat, 7 gün veya 90 gün uptime grafikleri üretmek için.
• Barındırma altyapısı: Status page uygulamasını barındırdığınız VPS, dedicated sunucu veya colocation altyapısı.

Burada kritik mimari karar: Status page’inizi, ana üretim ortamınızdan olabildiğince bağımsız konumlandırmak. Örneğin kritik web siteniz bir DCHost VPS üzerinde çalışıyorsa, status page’inizi ayrı bir DCHost lokasyonunda veya en azından farklı bir sunucuda konumlandırmanız, tam kesintiler sırasında bile durumu dışarıya aktarabilmenizi sağlar.

Uptime izleme mimarisine daha geniş bir açıdan bakmak isterseniz, web sitesi uptime izleme ve alarm kurma rehberimizde temel alarm stratejilerini detaylı biçimde ele almıştık. Bu yazıda ise o izleme verisini kullanıcıya taşıyan status page katmanına odaklanıyoruz.

Uptime Kuma ile Kendi Status Page’inizi Kurmak

Uptime Kuma, açık kaynaklı ve self-hosted bir uptime izleme ve status page aracıdır. Hafif bir uygulamadır, Docker ile birkaç komutla ayağa kaldırabilirsiniz, arayüzü sade ve özelleştirilebilirdir. Kendi DCHost VPS’inize kurduğunuzda hem veriniz sizde kalır, hem de istediğiniz gibi entegre edebilirsiniz.

Ön gereksinimler

Temel bir kurulum için ihtiyacınız olanlar:

• En az 1 vCPU ve 1–2 GB RAM’e sahip, Linux çalıştıran bir DCHost VPS veya sunucu
• Status page için kullanmak istediğiniz bir alan adı veya alt alan adı (ör: status.ornekalanadi.com)
• Sunucuya SSH erişimi ve temel Linux komutlarına hâkimiyet
• Tercihen Docker veya Docker Compose (ama zorunlu değil)

Docker ile hızlı Uptime Kuma kurulumu

Docker kullanıyorsanız Uptime Kuma’yı tek bir komutla çalıştırabilirsiniz. Örneğin:

docker run -d 
  --name uptime-kuma 
  -p 3001:3001 
  -v /opt/uptime-kuma:/app/data 
  --restart=always 
  louislam/uptime-kuma:latest

Bu komut Uptime Kuma’yı 3001 portunda çalıştırır ve veriyi /opt/uptime-kuma dizininde kalıcı olarak saklar. İlk kurulum sonrası tarayıcıdan http://sunucu-ip-adresiniz:3001 adresine gidip yönetici hesabınızı oluşturabilirsiniz.

Sunucunuzu sadece izleme ve status page için kullanıyorsanız, bu portu dışarı açık bırakabilirsiniz; ancak genelde Nginx veya başka bir web sunucusu üzerinden ters proxy (reverse proxy) kurup status alan adınızı buna yönlendirmek daha temiz bir çözümdür.

Nginx ile ters proxy ve SSL

Örneğin status.ornekalanadi.com alt alan adını kullanacaksanız:

1. DNS’te status alt alan adını Uptime Kuma’nın kurulu olduğu sunucunun IP’sine yönlendirin.
2. Sunucuda Nginx kuruluysa, Uptime Kuma’ya ters proxy yapan bir sanal host tanımı oluşturun.
3. Let’s Encrypt veya ticari bir SSL sertifikası ile HTTPS’i etkinleştirin.

SSL tarafını daha detaylı ele aldığımız HTTP’den HTTPS’ye geçiş rehberimiz, sertifika ve HSTS gibi gelişmiş ayarlar için yol gösterici olacaktır.

Yedekleme ve güncelleme stratejisi

Uptime Kuma, tüm yapılandırmasını ve geçmiş verisini tek bir data klasöründe tutar. Bu klasörü düzenli olarak DCHost yedek altyapınıza veya harici bir object storage’a almanız yeterli olur. Genel yedek stratejisi oluştururken, RPO/RTO odaklı yedekleme rehberimizden ilham alabilirsiniz.

Uptime Kuma’da Monitorlarınızı Tasarlamak

Status page’inizin doğruluğu, arka plandaki monitor’ların ne kadar iyi tasarlandığına bağlıdır. Sadece ana web sayfasına ping atmak çoğu senaryoda yeterli değildir; veritabanı, API, ödeme sistemi gibi kritik bileşenleri ayrıştırmak, kesintinin kapsamını daha net göstermeyi sağlar.

HTTP(S) kontrolleri: Uygulama katmanını ölçmek

En temel monitor türü HTTP(S) isteğidir. Uptime Kuma ile:

• Belirli bir URL’ye (ör: https://ornekalanadi.com/health) düzenli istek atabilirsiniz.
• Beklenen HTTP durum kodunu (200, 302 vb.) kontrol edebilirsiniz.
• Yanıt gövdesinde belirli bir anahtar kelime arayarak uygulamanın gerçekten düzgün döndüğünü doğrulayabilirsiniz.

Örneğin, WordPress sitenizde basit bir /healthcheck sayfası oluşturup içinde ‘OK’ ifadesi döndürürseniz, Uptime Kuma monitor’unu bu kelimeyi arayacak şekilde ayarlayabilirsiniz. Böylece sadece web sunucusunun değil, PHP uygulamasının da gerçekten çalışır olduğundan emin olursunuz.

Ping ve TCP port kontrolleri: Ağ ve servis düzeyi

HTTP kontrollerinin yanı sıra, daha düşük seviyeli kontroller kurmak önemlidir:

• Ping (ICMP): Sunucunun ağa erişilebilirliğini test eder. HTTP başarısız ama ping başarılıysa sorun genellikle web sunucusu veya uygulama katmanındadır.
• TCP port: Örneğin 3306 portundan veritabanı, 6379’dan Redis veya 25’ten SMTP servisinin erişilebilirliğini izleyebilirsiniz.

Bu tür çok katmanlı kontrollerle, kesintinin nerede olduğu hakkında daha net fikir sahibi olur ve status page üzerinde ilgili bileşenleri doğru etiketleyebilirsiniz. İzleme mimarinizde hangi senaryoları düşünmeniz gerektiği konusunda, VPS izleme ve alarm kurulumu rehberimizde daha gelişmiş örnekler bulabilirsiniz.

SSL sertifika süresi, DNS ve diğer kontroller

Uptime Kuma; SSL sertifika süre sonu, DNS çözümlemesi gibi ek metrikleri de izleyebilir. Bu sayede örneğin sertifikanız bitmeden belirli gün önce alarm alabilir, DNS’te yanlışlıkla silinen bir kaydı daha hızlı yakalayabilirsiniz. Özellikle çok sayıda alan adı ve alt alan adınız varsa, status page’inizi sertifika ve DNS sağlığını da yansıtan merkezi bir gösterge paneli gibi düşünebilirsiniz.

Monitor grupları ve etiketler

Uptime Kuma, monitor’ları gruplar ve etiketlerle kategorize etmenize izin verir. Örneğin:

• ‘Ön yüz’, ‘API’, ‘Veritabanı’, ‘Ödeme Servisi’ gibi servis bazlı gruplar
• ‘Avrupa DC’, ‘Türkiye DC’ gibi lokasyon bazlı etiketler
• ‘Kritik’, ‘Orta’, ‘Düşük’ önem seviyeleri

Bu sınıflandırma, status page üzerinde bileşen yapısını daha okunabilir hale getirir ve hangi kesintinin gerçekten kritik olduğunu hem size hem müşteriye daha net gösterir.

Status Page Tasarımı: Kullanıcıya Nasıl Görünecek?

Uptime Kuma, topladığı tüm bu monitor sonuçlarını herkese açık bir status page olarak yayınlayabilir. Burada amaç; teknik detayı abartmadan, ama yeterince bilgilendirici olacak şekilde durumu anlatmaktır.

Bileşen (component) bazlı görünüm

İyi tasarlanmış bir status page genellikle şu yapıya sahiptir:

• Üstte genel bir ‘Tüm sistemler çalışır durumda’ veya ‘Kısmi kesinti’ göstergesi
• Altında; ‘Web sitesi’, ‘API’, ‘Yönetim paneli’, ‘Ödeme servisi’ gibi bileşenler
• Her bileşenin yanında anlık durum (Operational, Degraded, Partial Outage vb.)

Bu yapıyı oluşturmak için, Uptime Kuma’daki monitor’larınızı bileşen bazlı gruplara ayırabilir ve status page üzerinde bu grupları ayrı satırlar halinde gösterebilirsiniz.

Geçmiş uptime grafikleri ve SLA görünürlüğü

Kullanıcılar sadece ‘şu an çalışıyor mu?’yu değil, ‘son 30 günde ne kadar kesinti oldu?’yu da görmek ister. Uptime Kuma, geçmiş başarısız kontrolleri ve kesintileri sakladığı için, uptime yüzdelerini ve geçmiş olumsuz olayları özetle gösterebilir. Böylece SLA taahhütlerinizin gerçekte ne kadar sağlandığını, müşteriye açık şekilde ispatlamış olursunuz.

SLA ve uptime yüzdelerini nasıl okumak gerektiği konusunda daha detaylı perspektif için, tekrar 99.9% uptime rehberine göz atmanız faydalı olacaktır.

Marka uyumu ve alan adı seçimi

Status page’inizi genellikle status.ornekalanadi.com gibi bir alt alan adında yayınlarız. Burada dikkat etmeniz gereken:

• Alt alan adının akılda kalıcı ve tahmin edilebilir olması
• Kurumsal sitenizde, yardım merkezinizde ve e-posta bildirimlerinizde bu URL’ye düzenli referans vermek
• Mümkünse logo, renk paleti gibi öğeleri ana markanızla uyumlu hale getirmek

Alan adı ve alt alan adı stratejisi tarafında daha geniş kapsamlı düşünmek isterseniz, subdomain mi klasör mü tercih etmelisiniz sorusunu detaylandırdığımız rehberimiz de işin SEO ve mimari kısmına ışık tutar.

Kesinti İletişimi Stratejisi: Ne Zaman, Ne Söylemeli?

Status page’in teknik kısmını kurmak işin yarısıysa, kesinti anında nasıl iletişim kuracağınız diğer yarısıdır. İyi bir status page:

• Kesinti başladığı anda otomatik olarak ‘incident’ açmanızı kolaylaştırır.
• Güncellemeleri tek yerden girmenizi, herkesin aynı bilgiyi okumasını sağlar.
• Olay kapandıktan sonra kısa bir kök neden analizi (RCA) paylaşmanıza imkân tanır.

Temel iletişim prensipleri

Pratikte işe yarayan birkaç prensip:

• Erken bildirim: Henüz tüm detayları bilmiyor olsanız bile, ‘Sorunun farkındayız, üzerinde çalışıyoruz’ mesajı atmak kullanıcıyı sakinleştirir.
• Net etki tanımı: ‘Tüm kullanıcılar giriş yapamıyor’ ile ‘Sadece yönetim panelinde yavaşlama var’ aynı şey değildir; kapsamı açık yazın.
• Zaman tahmini: ‘Çalışıyoruz’ cümlesi yerine, mümkünse ‘Şu anda X adımındayız, 30 dakika içinde yeni güncelleme paylaşacağız’ gibi somut zaman aralıkları verin.
• Kök neden özeti: Olay kapandıktan sonra, teknik detaylara boğmadan ‘ne oldu, tekrar olmaması için ne yaptık’ sorularını yanıtlayın.

Planlı bakım durumları içinse, bakımı önceden duyurmak ve bakım modunda doğru sayfayı göstermek çok kritiktir. Bu konuda adım adım örnekler için, bakım modu ve planlı kesinti yönetimi rehberimizi mutlaka okumanızı öneririm.

Bildirim kanalları ve otomasyon

Uptime Kuma; e-posta, Telegram, Discord, Slack benzeri birçok bildirim kanalına entegre olabilir. Tipik bir kurulumda:

• Kritik servisler için 7/24 görevli ekibin olduğu kanal(lar)a gerçek zamanlı bildirim gönderirsiniz.
• Daha az kritik bileşenler için sadece iş saatlerinde bildirim veya günlük özet raporlar kullanabilirsiniz.
• Status page güncellemelerini de bu kanallara otomatik duyuran entegrasyonlar kurabilirsiniz.

Böylece hem teknik ekibiniz hem de müşteri ilişkileri ekibiniz, kesinti anında statik bir sayfa yerine canlı güncellemelerle hareket eder.

Gelişmiş Senaryolar: Çok Bölgeli Mimariler ve Failover

Daha olgun altyapılarda status page, sadece ‘çalışıyor / çalışmıyor’ göstergesinden öteye geçer ve çok bölgeli (multi-region) mimarinin bir parçası haline gelir. Örneğin web sitenizi iki farklı veri merkezinde veya iki farklı DCHost lokasyonunda aktif-aktif ya da aktif-pasif olarak çalıştırıyorsanız, status page’iniz bu bölgelerin durumunu ayrı ayrı gösterebilir.

Bölge bazlı status gösterimi

Uptime Kuma’da her bölge için ayrı monitor setleri tanımlayıp bunları ‘Türkiye Bölgesi’, ‘Avrupa Bölgesi’ gibi başlıklar altında gruplayabilirsiniz. Böylece bir bölgede kısmi sorun yaşanırken diğer bölge sağlıklıysa, status page üzerinden bunu net şekilde iletirsiniz. Anycast DNS ve otomatik failover gibi tekniklerle birleştirildiğinde, kullanıcılar sorunu çoğu zaman fark etmese bile siz status page üzerinden şeffaf kalabilirsiniz.

Bu konuyu daha derinlemesine merak ediyorsanız, Anycast DNS ve otomatik failover rehberimiz, yüksek erişilebilirlik senaryolarını teknik detaylarıyla ele alıyor.

Diğer izleme sistemleriyle entegrasyon

Birçok ekipte Uptime Kuma, Prometheus, Grafana gibi çözümlerle birlikte kullanılıyor:

• Prometheus ile düşük seviye metrikleri (CPU, RAM, disk I/O, sorgu sayıları) toplarken,
• Uptime Kuma ile dışarıdan bakarak HTTP, ping, port vb. sağlığını izleyebilirsiniz.
• Status page’de ise bu son katman, kullanıcıya yansır.

Bu modelde Prometheus/Grafana panelleri daha çok iç operasyon ve derin analiz için, Uptime Kuma status page ise müşteri iletişimi için kullanılır. Zaten VPS izleme ve alarm kurulumu yazımızda da bu çok katmanlı yaklaşımı önermiştik.

DCHost Altyapısı Üzerinde Status Page Konumlandırma Önerileri

DCHost olarak kendi projelerimizde ve müşterilerimizde gördüğümüz en sağlıklı yaklaşım, status page altyapısını ana üretim ortamından mantıksal olarak ayırmak:

• Üretim siteniz DCHost paylaşımlı hosting veya belirli bir VPS’teyse, status page için küçük ama ayrı bir DCHost VPS ayırmak.
• Bu VPS’i tercihen farklı bir veri merkezi veya en azından farklı fiziksel node üzerinde konumlandırmak.
• DNS, SSL sertifikaları ve yedeklemeleri bu VPS özelinde de ayrı ayrı planlamak.

Böylece, en kötü senaryoda bile (örneğin ana sunucunuzun tamamen devre dışı kalması), status page’iniz üzerinden durumu açıklamaya ve ETA (tahmini çözüm süresi) paylaşmaya devam edebilirsiniz. Altyapınızı büyüttükçe, status page’inizi; yedekleme stratejiniz, felaket kurtarma planınız ve çok bölgeli mimarinizle birlikte düşünmeniz, kesintilere karşı dayanıklılığınızı ciddi şekilde artıracaktır.

Sonuç: Uptime Kuma ile Kendi Status Page’iniz İçin Yol Haritası

Özetleyelim: Kendi status page’inizi kurmak, sadece ‘şık bir ekstra’ değil, olgun bir altyapının temel bileşenlerinden biri. Uptime Kuma gibi self-hosted bir araçla:

• Uygulama, veritabanı, API ve kritik dış servislere ayrı ayrı monitor’lar kurup
• Bunları bileşen bazlı, okunabilir bir status page üzerinde birleştirerek
• Kesinti anında net, zamanında ve şeffaf iletişim kurabilir
• Geçmiş uptime verinizle SLA taahhütlerinizi ölçüp raporlayabilirsiniz.

Pratik bir başlangıç planı şöyle olabilir:

1. Küçük bir DCHost VPS ayırın ve Uptime Kuma’yı Docker ile kurun.
2. Ana web siteniz, API’niz ve kritik port’larınız için temel monitor’ları tanımlayın.
3. Status alt alan adınızı bu sunucuya yönlendirip Nginx + SSL ile HTTPS’i tamamlayın.
4. En çok kullanılan hizmetleriniz için bileşen yapısını oluşturup ilk status page’inizi yayınlayın.
5. İlk gerçek kesitte, bu rehberdeki iletişim prensiplerini uygulayarak incident yönetimini test edin.

Uptime ve kesinti yönetimini daha da olgunlaştırmak isterseniz, öncelikle uptime izleme ve alarm kurma rehberimize, ardından da Anycast DNS ve otomatik failover yazımıza göz atmanızı öneririm. Altyapınızı DCHost üzerinde kurgularken status page’i en baştan mimarinin parçası olarak düşünmek, ileride yaşayacağınız zor anları ciddi ölçüde yumuşatacaktır.