09 Eyl 2025·8 dk
SaaS Durum Sayfası Oluşturma: Olay Geçmişi ile Nasıl Hazırlanır
Kesinti sırasında müşterilerin haberdar kalması için olay geçmişi, net mesajlar ve aboneliklerle bir SaaS durum sayfasını nasıl planlayıp yayınlayacağınızı öğrenin.
Kesinti sırasında müşterilerin haberdar kalması için olay geçmişi, net mesajlar ve aboneliklerle bir SaaS durum sayfasını nasıl planlayıp yayınlayacağınızı öğrenin.
Bir SaaS durum sayfası, ürününüzün şu anda çalışıp çalışmadığını ve çalışmıyorsa neler yaptığınızı gösteren herkese açık (veya sadece müşterilere açık) bir web sitesidir. Olaylar sırasında tek gerçek kaynak haline gelir; sosyal medyadan, destek taleplerinden ve söylentilerden ayrıdır.
Beklediğinizden daha fazla kişiye yardımcı olur:
İyi bir servis durum sitesi genellikle üç ilişkili (ama farklı) katman içerir:
Amaç açıklık: gerçek zamanlı durum “Ürünü kullanabilir miyim?” sorusuna cevap verirken, geçmiş “Bu ne kadar sık oluyor?” sorusuna; postmortemler ise “Neden oldu ve ne değişti?” sorusuna yanıt verir.
Bir durum sayfası güncellemeler hızlı, sade dilde ve etki konusunda dürüst olduğunda işe yarar. İletişim için mükemmel bir teşhis yapmanıza gerek yok. Ancak zaman damgaları, etki kapsamı (kim etkilendi) ve bir sonraki güncelleme zamanı olmalı.
Durum sayfasına güveneceksiniz: kesintiler, azalmış performans (yavaş girişler, geciken webhook'lar) ve kısa aksamalara sebep olabilecek planlı bakımlar sırasında.
Durum sayfasını bir operasyon sayfası olarak değil bir ürün yüzeyi olarak ele aldığınızda: sahipleri belirleyebilir, şablonlar oluşturabilir ve izlemeyi bağlayabilirsiniz; her olayda süreci yeniden icat etmeniz gerekmez.
Bir araç seçmeden veya tasarım yapmadan önce, durum sayfanızın ne yapması gerektiğine karar verin. Net bir hedef ve açık bir sahip, özellikle herkes meşgulken ve bilgiler karışıksa sayfayı yararlı kılar.
Çoğu SaaS ekibi durumu şu üç pratik çıktıya göre oluşturur:
Lansmandan sonra takip edebileceğiniz 2–3 ölçülebilir sinyal yazın: kesintiler sırasında daha az yinelenen ticket, ilk güncelleme süresinde hızlanma veya daha fazla abone.
Birincil okuyucunuz genellikle teknik olmayan bir müşteridir ve bilmek ister:
Bu nedenle jargondan kaçının. “Bazı müşteriler giriş yapamıyor” demek, “auth üzerinde yükselmiş 5xx oranları” demekten daha açıktır. Teknik detaya ihtiyaç varsa, kısa bir ikincil cümle halinde verin.
Baskı altında sürdürebileceğiniz bir ton seçin: sakin, olgusal ve şeffaf. Önceden karar verin:
Sahipliği açıkça belirtin: durum sayfası “herkesin işi” olmamalı, yoksa kimsenin işi olmaz.
İki yaygın seçenek vardır:
Ana uygulamanız çökerse, bağımsız bir durum sitesi genelde daha güvenlidir. Yine de uygulamanızdan ve yardım merkezinden (örneğin /help) belirgin şekilde link verebilirsiniz.
Bir durum sayfası, arkasındaki “harita” kadar kullanışlıdır. Renkleri seçmeden ve metin yazmadan önce gerçekten neyi rapor edeceğinize karar verin. Amaç, müşterilerin ürününüzü nasıl deneyimlediğini yansıtmak—not organizasyon şemanızı.
Müşterinin “bozuk” dediğinde tanımlayabileceği parçaları listeleyin. Birçok SaaS ürünü için pratik başlangıç seti şöyle görünür:
Birden fazla bölge veya katman sunuyorsanız bunu da kaydedin (örn. “API – US” ve “API – EU”). İsimleri müşteri dostu tutun: “Giriş” “IdP Gateway”den daha açıklayıcıdır.
Müşterilerin servis hakkında nasıl düşündüğüne uyan bir gruplaya seçin:
Uzun bir liste oluşturmaktan kaçının. Entegrasyonlarınız onlarca ise, bir ana bileşen (“Entegrasyonlar”) ve birkaç yüksek etkili alt bileşen (“Salesforce”, “Webhooks”) düşünün.
Basit, tutarlı bir model karışıklığı önler. Yaygın seviyeler:
Her seviye için dahili kriterler yazın (her ne kadar yayınlamasanız bile). Örneğin, “Partial Outage = bir bölge kapalı” veya “Degraded = p95 gecikme X eşik üzerinde Y dakika”. Tutarlılık güven inşa eder.
Çoğu kesinti üçüncü tarafları içerir: bulut barındırma, e-posta teslimi, ödeme işlemcileri veya kimlik sağlayıcıları. Bu bağımlılıkları belgelendirin ki olay güncellemeleriniz doğru olsun.
Bunları herkese açık gösterip göstermemek kitlenize bağlıdır. Eğer müşteriler doğrudan etkilenebiliyorsa (ör. ödemeler), bir bağımlılık bileşenini göstermek yardımcı olabilir. Eğer gürültü katıyor veya suçlama yaratıyorsa, bağımlılıkları dahili tutup gerektiğinde güncellemelerde referans verin (ör. “Ödeme sağlayıcımızdan gelen artan hataları araştırıyoruz”).
Bu bileşen modelini oluşturduktan sonra, durum sayfası kurulumunun geri kalanı çok daha kolay olur: her olay başlangıçtan itibaren net bir “nerede” (bileşen) ve “ne kadar kötü” (durum) alır.
Bir durum sayfası, müşterinin sorularını saniyeler içinde yanıtladığında en kullanışlıdır. İnsanlar genellikle gergindir ve çok fazla gezinme istemezler.
En üstte önceliklendirin:
Açık bir dil kullanın. “API isteklerinde artan hata oranları” “üst akışta kısmi kesinti” demekten daha nettir. Teknik terim kullanmanız gerekirse kısa bir çeviri ekleyin (“Bazı istekler başarısız olabilir veya zaman aşımına uğrayabilir”).
Güvenilir bir desen:
Bileşen listesi için etiketleri müşteri odaklı tutun. İç hizmetiniz “k8s-cluster-2” ise müşteriler muhtemelen “API” veya “Background Jobs” görmek ister.
Sayfayı baskı altında okunabilir yapın:
Üstte küçük bir bağlantı seti koyun (başlıkta veya afişin hemen altında):
Amaç güven: müşteriler hemen ne olduğunu, neyi etkilediğini ve ne zaman haber alacaklarını anlamalı.
Bir olay çıktığında ekip teşhis, hafifletme ve müşteri sorularıyla uğraşıyor. Şablonlar belirsizliği ortadan kaldırır; farklı kişiler yayınlasa bile güncellemeler tutarlı, açık ve hızlı kalır.
İyi bir güncelleme her zaman aynı temel gerçeklerle başlar. En azından şu alanları standartlaştırın ki müşteriler hızlıca anlayabilsin:
Olay geçmişi sayfası yayınlıyorsanız, bu alanları tutarlı tutmak geçmiş olayları taramayı ve karşılaştırmayı kolaylaştırır.
Kısa güncellemeler hedefleyin; her seferinde müşterilerin aynı sorularını yanıtlasın. Kopyalayabileceğiniz pratik bir şablon:
Başlık: Kısa, belirgin özet (örn. “EU bölgesi için API hataları”)
Başlangıç zamanı: YYYY-MM-DD HH:MM (TZ)
Etkilenen bileşenler: API, Dashboard, Payments
Etkisi: Kullanıcıların gördüğü şey (hatalar, zaman aşımı, bozulmuş performans) ve kim etkilendi
Bildiğimiz: Neden hakkında bir cümle doğrulandıysa (varsayımdan kaçının)
Yaptıklarımız: Somut eylemler (rollback, ölçekleme, tedarikçi ile yükseltme)
Sonraki güncelleme: Tekrar yayınlayacağınız zaman
Güncellemeler:
Müşteriler sadece bilgi değil, öngörülebilirlik ister.
Planlı bakım sakin ve yapılandırılmış görünmelidir. Bakım gönderilerini standartlaştırın:
Bakım dilini özgül tutun (ne değişiyor, kullanıcılar ne fark edebilir) ve fazla söz vermekten kaçının—müşteriler doğruluk değer verir.
Olay geçmişi sadece bir günlük değil—müşterilerin (ve ekibinizin) sorunların ne sıklıkta olduğunu, hangi tür problemlerin tekrar ettiğini ve nasıl yanıt verdiğinizi hızlıca anlamasını sağlar.
Açık bir geçmiş şeffaflık yoluyla güven oluşturur. Ayrıca eğilim görünürlüğü sağlar: örneğin her birkaç haftada bir tekrar eden “API gecikmesi” olayları varsa, performans çalışmasına yatırım yapmanız gerektiğini gösterir. Zamanla tutarlı raporlama destek taleplerini azaltabilir çünkü müşteriler kendi cevaplarını bulabilir.
Müşteri beklentileri ve ürün olgunluğunuza uyan bir saklama penceresi seçin.
Ne seçerseniz seçin, açıkça belirtin (örn. "Olay geçmişi 12 ay saklanır").
Tutarlılık taramayı kolaylaştırır. Öngörülebilir bir adlandırma formatı kullanın:
YYYY-MM-DD — Kısa özet (örn. “2025-10-14 — Geciken e-posta teslimi”)
Her olay için en az gösterin:
Postmortem yayınlıyorsanız, olay detay sayfasından incelemeye bağlantı verin (örneğin: “Read the postmortem” bağlantısı). Bu, zaman çizelgesini temiz tutarken daha ayrıntı isteyen müşterilere seçenek sunar.
Müşteriler durum sayfasını kontrol etmeyi unutabilir. Abonelikler bu işi tersine çevirir: müşteriler otomatik olarak güncellemeler alır, sayfayı yenilemeye veya destekle iletişime geçmeye gerek kalmaz.
Çoğu ekip en az birkaç seçenek bekler:
Birden fazla kanal destekliyorsanız, kayıt akışını tutarlı tutun ki müşteriler dört farklı şekilde kayıt olur gibi hissetmesin.
Abonelikler her zaman opt-in olmalıdır. Özellikle SMS için, onaylamadan önce ne alacaklarını açıkça belirtin.
Abonelere kontrol verin:
Bu tercihler uyarı yorgunluğunu azaltır ve bildirimlerin güvenilir kalmasını sağlar. Bileşen düzeyinde abonelik yoksa, önce “Tüm güncellemeler” ile başlayıp filtrelemeyi sonra ekleyin.
Bir olay sırasında mesaj hacmi artar ve üçüncü taraf sağlayıcılar trafiği sınırlayabilir. Şunları kontrol edin:
Çeyreklik test gibi düzenli testler yapmak, aboneliklerin gerektiğinde çalıştığından emin olmanıza yardımcı olur.
Durum ana sayfasında abone olma çağrısını öne koyun—mümkünse kat üstünde—ki müşteriler bir sonraki olaydan önce kaydolabilsin. Mobilde görünür olsun ve müşterilerin yardım aradığı yerlerde (uygulama footer'ı, yardım merkezi veya /help) link verin.
Durum sayfanızı nasıl kuracağınız “yapabilir miyiz?”den çok neyi optimize etmek istediğinizle ilgilidir: lansman hızı, olay anındaki güvenilirlik ve devam eden bakım maliyeti.
Hosted araç genellikle en hızlı yoldur. Hazır bir durum sayfası, abonelikler, olay zaman çizelgeleri ve genellikle yaygın izleme sistemleriyle entegrasyon sunar.
Hosted araçta aramanız gerekenler:
DIY tam kontrol istiyorsanız iyi bir seçim olabilir; tasarım, veri saklama ve olay geçmişinin sunumu tamamen sizin olur. Dezavantajı güvenilirlik ve işletme sorumluluğudur.
Pratik bir DIY mimarisi:
Kendiniz barındırıyorsanız başarısızlık durumlarını planlayın: birincil veritabanınız kullanılamazsa veya deploy pipeline'ınız bozulursa ne olur? Birçok ekip durum sayfasını ana üründen ayrı altyapıda (hatta ayrı sağlayıcıda) tutar.
DIY kontrolünü istiyor ama her şeyi baştan yazmak istemiyorsanız, sohbet odaklı bir spec'ten özel bir durum sitesi (web UI + küçük bir olay API'si) hızlıca kurmanıza yardımcı olacak Koder.ai gibi bir platform işinizi kolaylaştırabilir. Bu, özellikle özelleştirilmiş bileşen modelleri, özel olay geçmişi UX veya dahili yönetici akışları isteyen ekipler için kullanışlıdır—aynı zamanda kaynak kodu dışa aktarıp hızlıca dağıtmanıza izin verir.
Hosted araçların aylık ödemeleri öngörülebilir; DIY mühendislik zamanı, barındırma/CDN maliyetleri ve devam eden bakım gerektirir. Ekip için seçenekleri karşılaştırıyorsanız, beklenen aylık harcamayı ve gerekli iç zaman maliyetini çıkarın—sonra bütçenizle karşılaştırın (bakınız pricing).
Durum sayfası gerçeği hızlı yansıtmalı. Bunu yapmanın en kolay yolu; sorunları tespit eden (izleme) sistemleri, yanıt koordinasyonunu sağlayan (olay iş akışı) sistemlerle bağlayıp güncellemelerin tutarlı ve zamanında olmasını sağlamaktır.
Çoğu ekip üç veri kaynağını birleştirir:
Pratik bir kural: izleme tespit eder; olay iş akışı koordine eder; durum sayfası iletişim kurar.
Otomasyon kritik anlarda dakikalar kazandırabilir:
İlk kamu mesajını muhafazakar tutun. “Araştırılıyor: artan hatalar” doğrulanmadan “Kesinti doğrulandı” demekten daha güvenlidir.
Tam otomatik mesajlaşma ters tepebilir:
Otomasyonu taslak ve öneri oluşturmak için kullanın; Identified, Mitigated ve Resolved durumları için insan onayı şart koşun.
Durum sayfasını müşteri odaklı bir kayıt defteri gibi yönetin. Şunları cevaplayabildiğinizden emin olun:
Bu denetim izi, olay sonrası incelemeler için faydalıdır, devralmalarda karışıklığı azaltır ve müşteriler açıklama istediğinde güven oluşturur.
Bir durum sayfası, ürününüz çalışmadığında erişilebilir olmalı. En yaygın hata, durum sitesini ana uygulamanızla aynı altyapıda kurmaktır—uygulama çöktüğünde durum sayfası da kaybolur ve müşterilerin bilgi kaynağı kalmaz.
Mümkünse durum sayfasını üretim uygulamanızdan farklı bir sağlayıcıda barındırın (veya en azından farklı bir bölge/hesap). Amaç blast-radius ayrımı: uygulama platformunuzdaki bir kesinti, iletişim kanallarınızı da etkilememeli.
DNS'i ayırmayı da düşünün. Ana domain'inizin DNS'i uygulama kenarı/CDN ile aynı yerde yönetiliyorsa bir DNS veya sertifika problemi her ikisini de engelleyebilir. Birçok ekip ayrı bir alt alan (ör. status.yourcompany.com) kullanır ve DNS'i bağımsız olarak yönetir.
Varlıkları hafif tutun: az JavaScript, sıkıştırılmış CSS ve sayfayı render etmek için ana uygulamanızın API'larına bağımlı olmayan kaynaklar. Durum sayfasının önüne bir CDN koyun ve statik kaynaklar için önbellekleme etkinleştirin ki yoğun trafik altında bile açılsın.
Pratik bir güvenlik ağı: bir yedek statik mod:
Müşterilerin hizmet sağlığını görmesi için giriş yapması gerekmemeli. Durum sayfasını halka açık tutun; yönetici/düzenleyici araçları ise kimlik doğrulama (tercihen SSO) ve güçlü erişim kontrolleri ile koruyun, denetim günlüklerini açık tutun.
Son olarak, başarısızlık senaryolarını test edin: staging ortamında uygulama origin'inizi geçici olarak engelleyin ve durum sayfasının hâlâ çözüldüğünü, hızlı yüklendiğini ve gerektiğinde güncellenebildiğini doğrulayın.
Bir durum sayfası, gerçek olaylarda tutarlı güncellemeler yaparsa güven oluşturur. Bu tutarlılık tesadüfen olmaz—açık sahiplik, basit kurallar ve öngörülebilir bir ritim gerekir.
Çekirdek ekibi küçük ve açık tutun:
Küçük bir ekipseniz, bir kişi iki rolü üstlenebilir—sadece önceden karar verin. Rol geçişlerini ve yükseltme yollarını on-call el kitabınıza (bakınız /docs/on-call) dokümante edin.
Bir uyarı müşteri etkileyen bir olaya dönüşünce, tekrar edilebilir bir akış izleyin:
Pratik kural: ilk güncellemeyi 10–15 dakika içinde yayınlayın, sonra etki devam ettiği sürece her 30–60 dakika güncelleme yapın—durum “Değişiklik yok, hâlâ araştırıyoruz” olsa bile.
1–3 iş günü içinde hafif bir olay sonrası inceleme yapın:
Sonra olay girdisini nihai özetle güncelleyin ki olay geçmişi sadece “çözüldü” mesajlarıyla dolu olmasın.
Bir durum sayfası, kolay bulunabiliyor, güvenilir ve tutarlı güncellemeler yapıyorsa değerlidir. Duyurmadan önce bir "prod-ready" kontrolü yapın—sonra hafif bir döngüyle zaman içinde iyileştirin.
Metin ve yapı
Markalama ve güven
Erişim ve izinler
Tam iş akışını test edin
Duyurun
Kendi durum sitenizi kuruyorsanız, aynı lansman kontrol listesini önce staging ortamında çalıştırmayı düşünün. Koder.ai gibi araçlar, web UI, yönetici ekranları ve backend uç noktalarını tek bir spec'ten üreterek bu yineleme döngüsünü hızlandırabilir—sonra kodu dışa aktarır ve istediğiniz yerde dağıtırsınız.
Aylık olarak birkaç basit çıktıyı takip edin:
Geçmişi eyleme geçirilebilir kılmak için basit bir etiketleme tutun:
Zamanla küçük iyileştirmeler—daha net ifadeler, daha hızlı güncellemeler, daha iyi kategorilendirme—daha az kesinti, daha az ticket ve artan müşteri güveni olarak birleşir.
Bir SaaS durum sayfası, mevcut hizmet durumu ve olay güncellemelerini tek bir resmi yerde gösteren özel bir sayfadır. Bu, “Çöktü mü?” sorusunu azaltır, aksaklıklar sırasında beklentileri belirler ve zaman damgalı, açık iletişimle güven oluşturur.
Gerçek zamanlı durum “Şu anda ürünü kullanabilir miyim?” sorusuna bileşen düzeyinde cevap verir.
Olay geçmişi “Bu ne sıklıkla oluyor?” sorusuna geçmiş olaylar ve bakım zaman çizelgesi ile yanıt verir.
Olay incelemeleri (postmortem) “Neden oldu ve ne değişti?” sorusuna kök neden ve önleme adımlarıyla yanıt verir (genellikle olay kaydından bağlantı verilir).
2–3 ölçülebilir çıktı ile başlayın:
Bu hedefleri yazın ve aylık olarak gözden geçirin ki sayfa güncel kalsın.
Bir sahibi ve bir yedek atayın (genellikle on-call rotasyonu). Birçok ekip şu rolleri kullanır:
Ayrıca önceden kuralları tanımlayın: kim yayınlayabilir, onay gerekli mi ve minimum güncelleme sıklığı (örneğin büyük olaylarda 30–60 dakika).
Müşterilerin sorunları nasıl tanımladığına göre bileşenleri seçin; dahili servis adlarına göre değil. Yaygın bileşenler:
Güvenilirlik coğrafyaya göre farklıysa bölgeye göre ayırın (örn. “API – US”, “API – EU”).
Küçük, tutarlı bir seviyeler seti kullanın ve her biri için dahili kriterler yazın:
Tutarlılık, mükemmel kesinlikten daha önemlidir. Müşteriler tekrar eden kullanımda her seviyeyi öğrenirler.
Yararlı bir olay güncellemesi her zaman şunları içermelidir:
Kök nedeni henüz bilmiyorsanız bile kapsam, etki ve sonraki adımları iletebilirsiniz.
İlk “Investigating” güncellemesini çabuk yayınlayın (genelde doğrulanan etkiden sonra 10–15 dakika içinde). Sonra:
Takvime uyamayacaksanız sessiz kalmayıp beklentileri sıfırlayan kısa bir not yayınlayın.
Hosted araçlar hız ve güvenilirlik sağlar (çoğu durumda uygulamanız çöktüğünde bile çevrimiçi kalırlar) ve genellikle abonelikler ile entegrasyonları içerir.
DIY tam kontrol verir ama dayanıklılık sizin sorumluluğunuzdadır:
Müşterilerin zaten kullandığı kanalları sunun (genellikle e-posta ve SMS, ayrıca Slack/Teams veya RSS). Abonelikler opt-in olmalı ve şunları açıklamalısınız:
Trafik arttığında bildirimlerin çalıştığından emin olmak için teslim edilebilirlik ve oran limitlerini düzenli test edin.