Jak wygląda dobra publiczna strona statusu

Publiczna strona statusu to miejsce, do którego klienci kierują się podczas awarii. Dobra strona statusu zmniejsza liczbę zgłoszeń do supportu i buduje zaufanie. Z czego się składa.

Co musi mieć dobra strona statusu

Aktualny stan każdej kluczowej usługi. Nie tylko "wszystko OK", ale z podziałem na komponenty (API, web, dashboard, emailing, payment processing).
Historia incydentów z ostatnich 90 dni. Bez prób ukrywania czegokolwiek - przejrzysta historia buduje zaufanie.
Metryka uptime (zwykle za 30 dni) dla każdego komponentu, wyrażona przejrzystym procentem.
Planowana konserwacja. Baner z datą i opisem tego, co będzie niedostępne.
Aktywny incydent z osią czasu aktualizacji. Investigating → Identified → Monitoring → Resolved.
Formularz subskrypcji. Klienci otrzymują e-mail przy zmianie statusu i nie muszą wielokrotnie sprawdzać strony.

Jasna hierarchia komponentów

Zamiast pojedynczego wpisu "monitor" podziel usługę na komponenty, które mają sens z perspektywy klienta:

Web App - frontend (używany przez odwiedzających)
API - backend dla integracji programowych
Auth / Login - logowanie
Email delivery - e-maile transakcyjne
Background jobs - sync, fakturowanie, eksporty
Status page - meta komponent: sama strona statusu też może paść (dlatego powinna działać na innej infrastrukturze niż produkt)

Incident communication: anatomia dobrej aktualizacji

Podczas rzeczywistej awarii przestrzegaj tych faz:

Investigating - "Zidentyfikowaliśmy problem z [komponent]. Zespół bada przyczynę." (w ciągu 5 min od wykrycia)
Identified - "Przyczyną jest [krótko]. Pracujemy nad naprawą. ETA [czas]." (gdy wiesz, co powoduje problem)
Monitoring - "Wdrożyliśmy poprawkę. Obserwujemy, czy problem się nie powtórzy." (po wdrożeniu rozwiązania)
Resolved - "Incydent został rozwiązany. Czas trwania X minut. Postmortem w przygotowaniu." (po potwierdzonym przywróceniu)

Każda faza otrzymuje timestamp i własną aktualizację. Po incydencie opublikuj post-mortem (root cause, timeline i działania zapobiegające powtórzeniu).

Zasada: Nigdy nie używaj niejasnych fraz typu "experiencing some issues". Klienci chcą konkretów: "Logowanie zawodzi przy ~30 % prób. API działa normalnie. Web jest dostępny tylko w trybie read-only."

Hosting: zasada niezależnej infrastruktury

Strona statusu musi działać na innej infrastrukturze niż monitorowana usługa. Jeśli padnie ci region AWS, strona statusu hostowana w tym samym regionie padnie razem z nim - dokładnie w momencie, gdy klienci potrzebują jej najbardziej.

Praktyczne rozwiązania:

Hosting przez zewnętrzny SaaS (ePulz.io, Better Stack, Atlassian Statuspage)
Własna statyczna strona na CDN (Cloudflare Pages, Netlify) z endpointem API gdzie indziej
W ostateczności minimalna statyczna strona na Cloudflare z ręcznie aktualizowanym tekstem

Subscribers: e-mail i webhook

Klienci nie chcą bez przerwy odświeżać strony statusu. Dobra strona obsługuje więc:

Email subscribers - w ePulz.io dostępne dla zalogowanych użytkowników z płatnym planem (subskrypcje zbieramy tylko od zweryfikowanych kont, nie od anonimowych odwiedzających)
Webhook - dla zespołów, które chcą zintegrować status z własnym Slackiem lub PagerDuty

Anti-pattern: ukrywanie problemów

Pokusa, by oznaczyć awarię jako "degraded" zamiast "down" (albo nie pokazać jej wcale), jest duża, ale krótkowzroczna:

Klienci i tak zauważą awarię (przez własny monitoring, zgłoszenia do supportu czy media społecznościowe)
Tracisz zaufanie, gdy odkryją, że status pokazuje "OK" podczas oczywistej awarii
Tracisz realny obraz trendu uptime, który potrzebny jest do wewnętrznych decyzji

Najlepszą strategią jest radykalna przejrzystość. GitLab, Cloudflare i Stripe publikują szczegółowe post-mortemy nawet przy żenujących błędach, a społeczność to docenia.

SEO i brand

Strona statusu powinna:

Być pod stabilnym i łatwym do zapamiętania URL dla statusu usługi
Mieć własny branding (logo, kolory) - klient musi widzieć, że nadal jest na twojej stronie
Być indeksowana w Google (lepsza widoczność przy wyszukiwaniu "[brand] down")
Być podlinkowana z głównej strony (stopka "Status usługi")

Podsumowanie

Strona statusu to nie dekoracja. To narzędzie operacyjne, które podczas incydentu zmniejsza obciążenie supportu i buduje długoterminowe zaufanie. Inwestycja kilku godzin w poprawną konfigurację zwraca się już przy pierwszej większej awarii.

Stwórz stronę statusu w 5 minut

ePulz.io status pages z własnym brandingiem, email subscribers i incident timeline. 7 dni za darmo.

Wypróbuj ePulz.io →