SaaS Durum Sayfası Oluşturma: Olay Geçmişi ile Nasıl Hazırlanır

Bir SaaS Durum Sayfası Nedir (ve Neden Önemlidir)

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:

• Müşteriler hızla “Sadece ben miyim?” sorusunu yanıtlayıp beklemeye, yeniden denemeye veya bir geçici çözüme karar verebilir.
• Destek ekipleri onlarca talepte aynı açıklamayı tekrar etmek yerine tek bir resmi güncellemeye yönlendirebilir.
• Satış ve Müşteri Başarısı ekipleri zaman damgalı, doğru bilgilerle yenilemeleri ve kilit hesapları proaktif yönetebilir.

Gerçek zamanlı durum vs. olay geçmişi vs. postmortem

İyi bir servis durum sitesi genellikle üç ilişkili (ama farklı) katman içerir:

• Gerçek zamanlı durum: bileşenlerinizin (API, kontrol paneli, faturalama vb.) şu anda çalışıp çalışmadığı.
• Olay geçmişi sayfası: geçmiş olayların ve bakım işlerinin zaman çizelgesi, böylece müşteriler desenleri anlayabilir ve sorunların ele alındığını görebilir.
• Olay sonrası incelemeler (postmortemler): kök sebebi, düzeltmeleri ve önlem adımlarını açıklayan daha derin yazılar. Bunlar herkese açık veya etkilenen müşterilerle özel paylaşılabilir.

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.

Beklentileri belirleme: şeffaflık, hız ve netlik

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ı.

Yaygın kullanım anları

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.

Hedefleri, Kitlenizi ve Sahipliği Belirleyin

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.

Hedefi tanımlayın (başarı nasıl görünür)

Çoğu SaaS ekibi durumu şu üç pratik çıktıya göre oluşturur:

• Destek taleplerini azaltmak: “Çöktü mü?” sorusunu tek bir yerde yanıtlamak
• Güven inşa etmek: zamanında, sade dilde güncellemeler paylaşmak
• İletişimi hızlandırmak: Destek, Mühendislik, Satış ve Müşteri Başarısı arasında

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.

Hedef kitleyi ve okuma seviyesini belirleyin

Birincil okuyucunuz genellikle teknik olmayan bir müşteridir ve bilmek ister:

• Ürün şu an çalışıyor mu?
• Ne etkileniyor (giriş, API, faturalama vb.)?
• Sonraki adım ne olmalı?
• Ne zaman düzelecek?

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.

Tonu, kuralları ve sahipliği seçin

Baskı altında sürdürebileceğiniz bir ton seçin: sakin, olgusal ve şeffaf. Önceden karar verin:

• Kim güncelleme yayınlayabilir (tek bir rol mi yoksa nöbetçi rotasyonu mu)
• Kim onaylıyor (varsa) ve onay kaç dakika sürebilir
• Aktif olay sırasında minimum güncelleme sıklığı (örneğin her 30 dakika)

Sahipliği açıkça belirtin: durum sayfası “herkesin işi” olmamalı, yoksa kimsenin işi olmaz.

Nerede barınacağına karar verin

İki yaygın seçenek vardır:

• Bağımsız site (örn. status.yourcompany.com): daha net ayrım ve genellikle daha dayanıklı
• Alt yol (örn. /status): markalama ve analiz için daha basit

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.

Servislerinizi ve Bileşen Durum Modelinizi Haritalayın

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ı.

Bir bileşen envanteri ile başlayın

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:

• API
• Web uygulaması
• Dashboard / yönetim
• Kimlik doğrulama (giriş, SSO)
• Faturalama
• Entegrasyonlar (Slack, Salesforce, webhook'lar vb.)

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.

Bileşenleri nasıl gruplayacağınıza karar verin

Müşterilerin servis hakkında nasıl düşündüğüne uyan bir gruplaya seçin:

• Ürüne göre: farklı teklifiniz varsa (Ürün A vs Ürün B)
• Bölgeye göre: kullanılabilirlik coğrafi olarak farklıysa
• Özellik/iş akışına göre: müşteriler belirli görevleri kullanıyorsa (Raporlama, İçe Aktarma, Bildirimler)

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.

Durum seviyelerinizi ve anlamlarını tanımlayın

Basit, tutarlı bir model karışıklığı önler. Yaygın seviyeler:

• Operational: beklendiği gibi çalışıyor
• Degraded Performance: normalden daha yavaş veya aralıklı hatalar
• Partial Outage: anlamlı bir kullanıcı/özellik alt kümesi kullanılamıyor
• Major Outage: servis geniş ölçüde kullanılamıyor

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.

Bağımlılıkları kaydedin—ve neyi göstereceğinize karar verin

Ç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.

Basit, Müşteri Dostu Bir Durum Sayfası Tasarlayın

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.

Müşterilerin önce neye ihtiyaç duyduğunu öne koyun

En üstte önceliklendirin:

• Mevcut durum: Operasyonel mi, bozulma mı, yoksa kesinti mi?
• Etkisi: Ne etkileniyor (kim/ hangi bölgeler/ hangi özellikler) ve kullanıcılar ne deneyimleyebilir?
• ETA (varsa): Savunabileceğiniz zaman tahminleri paylaşın
• Bir sonraki güncelleme zamanı: “Bir sonraki güncelleme 14:30 UTC'ye kadar” gibi spesifik bir taahhüt tekrar ticket oluşturmayı azaltır

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”).

Basit, taranabilir bir düzen kullanın

Güvenilir bir desen:

1. Üst afiş: genel durum için (All Systems Operational / Degraded Performance / Major Outage)
2. Bileşen listesi: net durumlarla (Web App, API, Billing, Integrations vb.)
3. Aktif olaylar ve planlı bakımlar: hemen altında, en yeni güncellemelere göre sıralı

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.

Erişilebilirlik ve mobil temel özellikler

Sayfayı baskı altında okunabilir yapın:

• Güçlü renk kontrastı ve metin etiketleri (sadece renge dayanmayın)
• Tutarlı anlamlı simgeler (ör. yeşil = operasyonel, sarı = bozulma, kırmızı = kesinti)
• Mobil dostu boşluk ve dokunma hedefleri; birçok kullanıcı durumu telefonundan kontrol eder

İnsanların beklediği hızlı bağlantıları ekleyin

Üstte küçük bir bağlantı seti koyun (başlıkta veya afişin hemen altında):

• Subscribe (e-posta/SMS/webhook bildirimleri için)
• Incident History (geçmiş olaylar ve zaman çizelgeleri)
• Contact Support at /support

Amaç güven: müşteriler hemen ne olduğunu, neyi etkilediğini ve ne zaman haber alacaklarını anlamalı.

Olay ve Bakım Güncelleme Şablonları Oluşturun

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.

Her zaman yayınlayacağınız olay alanlarını tanımlayın

İ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 başlangıç zamanı (zaman dilimiyle)
• Etkilenen bileşenler/servisler (durum modelinize göre eşlenmiş)
• Müşteri etkisi (kim etkilendi ve nasıl)
• Mevcut durum (Investigating, Identified, Monitoring, Resolved)
• Güncellemeler günlüğü (zaman damgalı girdiler)
• Çözülme zamanı (servis normale döndüğünde)

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.

Basit, tekrarlanabilir bir olay güncelleme şablonu kullanın

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:

• HH:MM (TZ) — Investigating: …
• HH:MM (TZ) — Identified: …
• HH:MM (TZ) — Monitoring: …
• HH:MM (TZ) — Resolved: …

Güncelleme sıklığı kurallarını netleştirin

Müşteriler sadece bilgi değil, öngörülebilirlik ister.

• Büyük olaylar için, her 30–60 dakika güncelleme taahhüt edin; güncelleme “Hâlâ araştırıyoruz; ETA yok; bir sonraki güncelleme X” olsa bile.
• Küçük sorunlar için daha seyrek yayınlayabilirsiniz, yine de vaat edilen “bir sonraki güncelleme” zamanını ekleyin.
• Cadence'i karşılayamıyorsanız gecikmeyi kabul eden kısa bir not yayınlayın ve beklentileri sıfırlayın.

Bakım duyuru şablonları ekleyin

Planlı bakım sakin ve yapılandırılmış görünmelidir. Bakım gönderilerini standartlaştırın:

• Bakım penceresi: başlangıç/bitiş zamanı (zaman dilimiyle)
• Beklenen etki: none / degraded / intermittent / downtime
• Etkilenen bileşenler
• Müşteri eylemleri (varsa): “Herhangi bir işlem gerekmez” veya net adımlar
• Hatırlatma güncellemesi: bakım başladığında kısa bir gönderi ve bittiğinde bir diğer gönderi

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.

Taranması Kolay Bir Olay Geçmişi Oluşturun

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.

Olay geçmişi neden çabaya değer?

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.

Saklama süresini kararlaştırın: ne kadar geriye tutmalısınız?

Müşteri beklentileri ve ürün olgunluğunuza uyan bir saklama penceresi seçin.

• 90 gün: erken aşama SaaS için yaygın, sayfayı hafif tutar
• 6–12 ay: güvenilirlik değerlendiren kurumsal alıcılar için daha iyi
• Daha uzun: zaman çizelgesi gürültülü hale gelirse eski kayıtları ayrı bir arşive aktarın

Ne seçerseniz seçin, açıkça belirtin (örn. "Olay geçmişi 12 ay saklanır").

Her girişi anında anlaşılır yapın

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:

• etkilenen bileşenler
• başlangıç/bitiş zamanı (zaman dilimiyle)
• etki seviyesi (minor/major)
• kısa çözüm notu

Daha fazla bağlam varsa bağlantı verin

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.

Abonelikler ve Bildirimler Ekleyin

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.

Müşterilerinizin zaten kullandığı kanalları teklif edin

Çoğu ekip en az birkaç seçenek bekler:

• E-posta (çoğu müşteri için varsayılan)
• SMS (acil, yüksek sinyal uyarıları için en iyisi)
• Slack veya Microsoft Teams (iş müşterileri ve operasyon ekipleri için ideal)
• RSS/Atom (hala teknik kullanıcılar ve dahili araçlar için popüler)

Birden fazla kanal destekliyorsanız, kayıt akışını tutarlı tutun ki müşteriler dört farklı şekilde kayıt olur gibi hissetmesin.

Açık rıza ve tercihleri net yapın

Abonelikler her zaman opt-in olmalıdır. Özellikle SMS için, onaylamadan önce ne alacaklarını açıkça belirtin.

Abonelere kontrol verin:

• Kapsam: tüm olaylar mı yoksa seçili bileşenler mi
• Tür: sadece olaylar, sadece bakım veya her ikisi
• Şiddet: isteğe bağlı olarak sadece “Major outage” veya “Tüm güncellemeler”

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.

Bildirimlerin tam ihtiyaç anında başarısız olmamasını sağlayın

Bir olay sırasında mesaj hacmi artar ve üçüncü taraf sağlayıcılar trafiği sınırlayabilir. Şunları kontrol edin:

• Teslim edilebilirlik: e-posta için SPF/DKIM/DMARC; doğrulanmış gönderici alanları; müşterilerin tanıyacağı "from" adresleri
• Oran limitleri ve throttling: e-posta/SMS sağlayıcınızın kısıtları, Slack/Teams webhook limitleri ve yeniden deneme davranışı
• Yedekler: Slack gönderileri başarısız olursa hâlâ e-posta gönderiyor musunuz? SMS gecikiyorsa, durum ana sayfasında net bir afiş gösteriyor musunuz?

Çeyreklik test gibi düzenli testler yapmak, aboneliklerin gerektiğinde çalıştığından emin olmanıza yardımcı olur.

"Güncellemelere abone ol"u görünür yapın

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.

Yapım Yöntemi Seçin: Hosted Araç vs. Kendin Yap

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.

Seçenek 1: Hosted bir durum sayfası aracı kullanın

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:

• Güvenilirlik ve bağımsızlık: durum sayfası ana uygulamanız çökse bile ulaşılabilir olmalı
• API ve otomasyon: olay oluşturma, bileşen güncelleme ve ilerleme bildirimleri için API/webhook
• Erişim kontrolü: kim yayınlayabilir vs. taslak bırakabilir roller; SSO artı
• Markalama ve özel alan adı: logo/renkler ve status.yourcompany.com gibi bir domain
• Analitik: abone sayısı, güncelleme görüntülemeleri, e-posta teslim metrikleri
• Uyumluluk ihtiyaçları: düzenlenen ortamlarda denetim günlükleri ve saklama

Seçenek 2: Kendiniz inşa edin (DIY)

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:

• Statik site (hızlı, önbelleğe uygun) durum UI ve olay geçmişi sayfaları için
• API destekli veri kaynağı (veya hafif bir CMS) olayları, bileşenleri ve güncellemeleri depolamak için
• Sıkı önbellekleme + CDN böylece durum sayfanız kesinti sırasında bile hızlı kalır

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.

Maliyet planlaması

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).

İzleme ve Olay İş Akışıyla Bağlayın

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.

Durum güncellemeleri nereden gelmeli

Çoğu ekip üç veri kaynağını birleştirir:

• İzleme uyarıları (health check'ler, sentetik testler, hata oranları, gecikme, kuyruk derinliği). Bunlar tespit için iyidir, ama her zaman müşteri etkisini açıklamaz.
• Manuel güncellemeler: nöbetçi veya destek ekibi tarafından yapılan bağlamsal eklemeler: kim etkilendi, geçici çözümler, ne değişti.
• Olay yönetim araçları (PagerDuty, Opsgenie, Jira Service Management vb.). Bunlar durum sayfanızın özetleyebileceği zaman çizelgesini, rolleri ve çözüm notlarını sağlar.

Pratik bir kural: izleme tespit eder; olay iş akışı koordine eder; durum sayfası iletişim kurar.

Otomasyonun yardımı (ama abartmayın)

Otomasyon kritik anlarda dakikalar kazandırabilir:

• Yüksek öncelikli bir monitor tetiklendiğinde bir olay oluşturun (örn. "API hata oranı %5'i 5 dakika aştı"). Başlığı, etkilenen bileşenleri ve ilk şiddeti otomatik doldurun.
• Nesnel sinyaller için health check'lerden bileşenleri güncelleyin (örn. “Web app: Degraded Performance”)
• Durum değişikliklerini olay kanalınıza senkronize edin ki müdahale edenler müşterilerin gördüğünü görsün.

İlk kamu mesajını muhafazakar tutun. “Araştırılıyor: artan hatalar” doğrulanmadan “Kesinti doğrulandı” demekten daha güvenlidir.

İnsan incelemesi olmadan tam otomasyona gitmeyin

Tam otomatik mesajlaşma ters tepebilir:

• Gürültülü bir uyarı yanlış bir olay yayınlayabilir.
• Kısmi bir arıza, bir monitor için “down” görünebilir ama müşteriler etkilenmiyor olabilir.
• Otomatik çözülmeler kullanıcılar hâlâ etkilenirken olayı kapatabilir.

Otomasyonu taslak ve öneri oluşturmak için kullanın; Identified, Mitigated ve Resolved durumları için insan onayı şart koşun.

Denetim izi tutun

Durum sayfasını müşteri odaklı bir kayıt defteri gibi yönetin. Şunları cevaplayabildiğinizden emin olun:

• Kim olay durumunu değiştirdi?
• Ne değiştirildi (metin, bileşenler, zaman damgaları)?
• Ne zaman değiştirildi?

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.

Güvenilir Kılın: Barındırma, DNS ve Kesinti-Korumalı Yapı

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.

Ana yığından izole edin

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.

Sayfayı hızlı ve dayanıklı yapın

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:

• son bilinen durumu ve olay afişini önceden render edip saklayın
• bunu obje depolama veya statik barındırmadan sunun
• sistemler sağlıklı olduğunda dinamik güncelleyin, ama sağlıksızken zarif bir şekilde düşünsün

Varsayılan olarak herkese açık, yönetim için güvenli erişim

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.

Operasyonel Süreç: Kim Günceller ve Ne Zaman

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.

Rolleri tanımlayın (her şey bozulmadan önce)

Çekirdek ekibi küçük ve açık tutun:

• Incident Commander (IC): müdahaleyi yönetir, önceliği belirler ve kararlılığı onaylar
• Communications Lead: durum sayfasına güncelleme yapar ve dili müşteri dostu tutar
• Nöbetçi mühendisler: araştırır, hafifletir ve doğrulanmış bilgileri IC'ye iletir

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.

Her seferinde takip edilecek basit bir güncelleme kontrol listesi

Bir uyarı müşteri etkileyen bir olaya dönüşünce, tekrar edilebilir bir akış izleyin:

1. Acknowledge: hızlıca "Investigating" güncellemesi yayınlayın
2. Etkisini değerlendir: hangi bileşenler/bölgeler/müşteri segmentleri etkilendiğini doğrulayın
3. Güncelle yayınla: kullanıcıların neler görebileceğini, varsa geçici çözümleri ve bir sonraki güncelleme zamanını paylaşın
4. Çöz: servisin geri geldiğini doğrulayın ve neyi izlediğinizi belirtin
5. Özet: kısa bir özet ekleyin ve tam inceleme hazır olduğunda bağlantı verin

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.

Çözüm sonrası: gözden geçirin ve geliştirin

1–3 iş günü içinde hafif bir olay sonrası inceleme yapın:

• Zaman çizelgesi: tespitten kurtarmaya ana olaylar
• Kök neden (en iyi bilinen): sade dilde açıklama
• Aksiyon maddeleri: spesifik düzeltmeler, sahipler ve tarihleri

Sonra olay girdisini nihai özetle güncelleyin ki olay geçmişi sadece “çözüldü” mesajlarıyla dolu olmasın.

Lansman Kontrol Listesi ve Sürekli İyileştirme

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.

Lansman kontrol listesi (pratik versiyon)

Metin ve yapı

• Bileşen isimlerinin müşterilerin tanıdığı şekilde olduğundan emin olun (örn. “Dashboard” vs dahili servis adları).
• Kısa bir “Bu sayfa ne gösterir” intro ekleyin ve hesap-özel konular için destek linki verin (örn. /support).
• Olay güncellemelerinin müşteri etkisini açıkladığından ve sonraki adımları verdiğinden emin olun (örn. “ödemeler başarısız oluyorsa” ve “10 dakika sonra yeniden deneyin”).

Markalama ve güven

• Logonuzu, favicon'u ve durumlar için basit bir renk sistemi ekleyin (çok ince tonlardan kaçının).
• Net bir zaman damgası formatı ve zaman dilimi gösterin.

Erişim ve izinler

• Kimlerin olay yayınlayabileceğini, bakım planlayabileceğini ve sayfa ayarlarını düzenleyebileceğini doğrulayın.
• Güncellemelerin tek bir kişiye takılmaması için bir “on-call yedeği” kurun.

Tam iş akışını test edin

• Bir test olayı çalıştırın (test olduğunu açıkça işaretleyin ve çözüldü olarak işaretleyin).
• E-posta/SMS ile abone olun ve bildirimlerin doğru bağlantılar içerip içermediğini doğrulayın.

Duyurun

• Durum sayfası bağlantısını uygulama footer'ına, yardım merkezine ve destek otomatik yanıtlara ekleyin.
• Müşterilere ne bekleyebileceklerini ve nasıl abone olabileceklerini açıklayan kısa bir duyuru gönderin.

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.

"Daha iyi"nin neye benzediğini ölçün

Aylık olarak birkaç basit çıktıyı takip edin:

• Azalan ticket sayısı: olayla ilgili ticket hacmi karşılaştırması
• İlk güncellemede hız: tespit ile ilk kamu güncellemesi arasındaki süre
• Abone büyümesi: kanal bazında abone sayısı ve hangi bileşenleri takip ettikleri

Olay desenlerinden öğrenin

Geçmişi eyleme geçirilebilir kılmak için basit bir etiketleme tutun:

• Olayları kategori ile etiketleyin (performans, kısmi kesinti, üçüncü taraf, bakım, güvenlikle ilgili)
• Tekrarlayan bileşenler ve sık suçluları not edin
• Bunu düzeltmeleri önceliklendirmek ve post-incident incelemelerini bilgilendirmek için kullanın

SEO temelleri (müşterilerin doğru sayfayı bulması için)

• “Service Status” ve “Incident History” gibi net sayfa başlıkları kullanın.
• Başlıkları (H2/H3) yapılandırılmış tutun ki geçmiş sayfaları taraması kolay olsun.
• Tercihen indexlenebilir olay geçmişi sayfaları kullanın (güvenlik/mahremiyet gerekçesi yoksa) ve ana durum sayfası ile her olay arasındaki bağlantıların taranabilir olduğundan emin olun.

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.