Ako vyzerá dobrá public status stránka

V skratke: Public status stránka je miesto, kam idú zákazníci, keď im niečo nefunguje. Dobrá status page znižuje support tickets, buduje dôveru a zachraňuje váš tím od desiatok zopakovaných otázok počas incidentu.

Čo musí mať dobrá status page

1. Aktuálny stav každej kľúčovej služby. Nie iba "všetko OK" - rozdelené po komponentoch (API, web, dashboard, emailing, payment processing).
2. História incidentov za posledných 90 dní. Bez snahy ich skrývať. Honest history buduje dôveru.
3. Uptime metriku (typicky za 30 dní) pre každý komponent. Transparentné percento.
4. Plánovaná údržba. Banner s dátumom a popisom čo bude inaccessible.
5. Aktívny incident s post-update timeline-om. Investigating → Identified → Monitoring → Resolved.
6. Subscribe formulár - zákazníci dostanú email pri zmene stavu, nemusia opakovane checkovať.

Jasná hierarchia komponentov

Namiesto jedného "monitor" záznamu rozdelte na komponenty, ktoré dávajú zmysel z perspektívy zákazníka:

• Web App - frontend (návštevníci ho používajú)
• API - backend pre programové integrácie
• Auth / Login - prihlasovanie
• Email delivery - transactional emaily
• Background jobs - sync, fakturácia, exports
• Status page - sama meta - aj táto môže padnúť (preto by mala byť hostovaná na inej infraštruktúre než produkt)

Incident communication: anatómia dobrého update

Pri reálnom výpadku sledujte tieto fázy:

1. Investigating - "Identifikovali sme problém s [komponent]. Tím skúma príčinu." (do 5 min od detekcie)
2. Identified - "Príčinou je [stručne]. Pracujeme na fixe. ETA [čas]." (keď viete čo to spôsobuje)
3. Monitoring - "Fix sme nasadili. Sledujeme, či sa problém nezopakuje." (po nasadení riešenia)
4. Resolved - "Incident je vyriešený. Trvanie X minút. Postmortem nasleduje." (potvrdená obnova)

Každá fáza dostáva timestamp a update. Po incidente publikujte post-mortem (root cause, timeline, čo robíme aby sa to nezopakovalo).

Hosting: zásada nezávislej infraštruktúry

Status page musí bežať na inej infraštruktúre ako monitorovaná služba. Ak váš AWS region padne, vaša status page hostovaná na tom istom AWS region tiež padne - presne v moment, keď ju zákazníci najviac potrebujú.

Praktické riešenia:

• Hostovanie cez externú SaaS (StatusPage.io, ePulzio, Better Stack, Statuspage)
• Vlastná static stránka na CDN (Cloudflare Pages, Netlify) s API endpointom inde
• Worst case: minimálna statická stránka na Cloudflare so manuálne updatovaným textom

Subscribers: e-mail / RSS / webhook

Zákazníci nechcú opakovane refreshovať status page. Dobrá stránka podporuje:

• Email subscribers s double opt-in (potvrdzovací email po prihlásení)
• RSS / Atom feed - tradičný spôsob pre tech-savvy users
• Webhook - pre tímy, ktoré chcú integrovať do svojho Slack alebo PagerDuty

Anti-pattern: skrývanie problémov

Pokušenie je veľké označiť výpadok ako "degraded" namiesto "down", alebo ho vôbec neukázať. To je krátkozraké:

• Zákazníci ho aj tak zaregistrujú (vlastné monitoring, support ticket flow, sociálne siete)
• Strata dôvery, keď zistia, že status hovorí "OK" počas evidentného výpadku
• Žiadny obraz reálneho uptime trendu pre interné rozhodovanie

Najlepšia stratégia: radikálna transparentnosť. GitLab, Cloudflare, Stripe všetky publikujú detailné post-mortem aj pri trápnych chybách. Komunita to oceňuje.

SEO a brand

Status stránka by mala:

• Byť na vlastnej subdoméne (status.example.com) alebo URL prefixe
• Mať vlastný branding (logo, farby) - zákazník musí vedieť, že je na vašej stránke
• Byť indexovaná v Google (lepšia visibility pri "[brand] down" search)
• Linkovaná z hlavnej stránky (footer "Status služby")

Záver

Status page nie je dekorácia. Je to operatívny nástroj, ktorý znižuje support cost počas incidentu a buduje dlhodobú dôveru. Investícia 1-2 hodiny do správnej konfigurácie sa vráti pri prvom väčšom výpadku.