Status page best practices: kesintileri nasıl iletmeli

Kısaca: Halka açık bir status sayfası, müşterilerin bir şey çalışmadığında gittikleri yerdir. İyi bir status page support ticket'ları azaltır, güven inşa eder ve ekibinizi olay sırasında düzinelerce tekrarlanan sorudan kurtarır.

İyi bir status page'in sahip olması gerekenler

1. Her temel hizmetin mevcut durumu. Sadece "her şey OK" değil - bileşenlere göre bölünmüş (API, web, dashboard, emailing, payment processing).
2. Son 90 günün olay geçmişi. Onları gizlemeye çalışmadan. Dürüst geçmiş güven inşa eder.
3. Uptime metriği (genellikle 30 günlük) her bileşen için. Şeffaf yüzde.
4. Planlı bakım. Tarih ve neyin erişilemez olacağı açıklaması ile banner.
5. Post-update timeline ile aktif olay. Investigating → Identified → Monitoring → Resolved.
6. Subscribe formu - müşteriler durum değişikliğinde email alır, defalarca kontrol etmek zorunda kalmaz.

Net bileşen hiyerarşisi

Tek bir "monitor" kaydı yerine, müşteri perspektifinden anlamlı olan bileşenlere bölün:

• Web App - frontend (ziyaretçiler kullanır)
• API - programatik entegrasyonlar için backend
• Auth / Login - giriş
• Email delivery - işlemsel emailler
• Background jobs - sync, faturalama, exports
• Status page - meta'nın kendisi - bu bile düşebilir (bu yüzden üründen farklı altyapıda host edilmeli)

Olay iletişimi: iyi bir update'in anatomisi

Gerçek bir kesinti sırasında şu fazları takip edin:

1. Investigating - "[Bileşen] ile ilgili bir sorun belirledik. Ekip nedeni araştırıyor." (tespitten 5 dk içinde)
2. Identified - "Sebep [kısaca]. Fix üzerinde çalışıyoruz. ETA [zaman]." (sebebini bildiğinizde)
3. Monitoring - "Fix'i deploy ettik. Sorunun tekrarlanıp tekrarlanmadığını izliyoruz." (çözümü deploy ettikten sonra)
4. Resolved - "Olay çözüldü. Süre X dakika. Postmortem takip edecek." (onaylanmış kurtarma)

Her faz timestamp ve update alır. Olaydan sonra post-mortem yayınlayın (root cause, timeline, tekrar olmaması için ne yapıyoruz).

Kural: "Experiencing some issues" gibi belirsiz ifadeleri asla kullanmayın. Müşteriler somutluk ister: "Giriş denemelerinin ~%30'unda başarısız oluyor. API normal çalışıyor. Web sadece read-only modda mevcut."

Hosting: bağımsız altyapı ilkesi

Status page izlenen hizmetten farklı bir altyapıda çalışmalıdır. AWS bölgeniz düşerse, aynı AWS bölgesinde host edilen status page'iniz de düşer - tam müşterilerin en çok ihtiyaç duyduğu anda.

Pratik çözümler:

• Harici SaaS üzerinden hosting (StatusPage.io, ePulz.io, Better Stack, Statuspage)
• CDN'de kendi statik sayfa (Cloudflare Pages, Netlify) ve API endpoint başka yerde
• Worst case: Cloudflare'de manuel olarak güncellenen metinli minimum statik sayfa

Subscribers: e-mail / RSS / webhook

Müşteriler status page'i defalarca yenilemek istemez. İyi bir sayfa destekler:

• Email subscribers - ePulz.io'da ücretli plan ile giriş yapmış kullanıcılar için mevcut (sadece doğrulanmış hesaplardan abonelik topluyoruz, anonim ziyaretçilerden değil)
• RSS / Atom feed - tech-savvy users için geleneksel yol
• Webhook - Slack veya PagerDuty'ye entegre etmek isteyen ekipler için

Anti-pattern: sorunları gizlemek

Bir kesintiyi "down" yerine "degraded" olarak işaretlemek veya hiç göstermemek için cazibe büyüktür. Bu kısa görüşlüdür:

• Müşteriler yine fark edecek (kendi izleme, support ticket flow, sosyal ağlar)
• Status'un belirgin bir kesinti sırasında "OK" dediğini keşfettiklerinde güven kaybı
• İç karar verme için gerçek uptime trendinin hiçbir resmi yok

En iyi strateji: radikal şeffaflık. GitLab, Cloudflare, Stripe hepsi utanç verici hatalar için bile detaylı post-mortem yayınlıyor. Topluluk bunu takdir ediyor.

SEO ve marka

Status page şöyle olmalı:

• Kendi subdomain'inde (status.example.com) veya URL prefix'inde olmalı
• Kendi marka kimliğine sahip olmalı (logo, renkler) - müşteri sizin sayfanızda olduğunu bilmelidir
• Google'da indekslenmelidir ("[marka] down" aramasında daha iyi görünürlük)
• Ana sayfadan linklenmelidir (footer "Hizmet durumu")

Sonuç

Status page dekorasyon değildir. Olay sırasında support maliyetini azaltan ve uzun vadeli güven inşa eden operasyonel bir araçtır. Doğru yapılandırmaya yatırılan 1-2 saat, ilk büyük kesintide kendini geri öder.

5 dakikada status page oluşturun

Kendi marka kimliği, email subscribers ve incident timeline ile ePulz.io status pages. 7 gün ücretsiz.

ePulz.io'yu dene →