Best practice status page: come comunicare outage

In breve: Una status page pubblica è il posto dove i clienti vanno quando qualcosa non funziona. Una buona status page riduce i support ticket, costruisce fiducia e salva il tuo team da decine di domande ripetute durante un incident.

Cosa deve avere una buona status page

1. Stato attuale di ogni servizio chiave. Non solo "tutto OK" - diviso per componenti (API, web, dashboard, emailing, payment processing).
2. Storia degli incident degli ultimi 90 giorni. Senza tentare di nasconderli. Storia onesta costruisce fiducia.
3. Metrica uptime (tipicamente per 30 giorni) per ogni componente. Percentuale trasparente.
4. Manutenzione pianificata. Banner con data e descrizione di cosa sarà inaccessibile.
5. Incident attivo con timeline post-update. Investigating → Identified → Monitoring → Resolved.
6. Formulario subscribe - i clienti ricevono email al cambio di stato, non devono verificare ripetutamente.

Gerarchia chiara di componenti

Invece di un singolo record "monitor" dividi in componenti che hanno senso dalla prospettiva del cliente:

• Web App - frontend (i visitatori lo usano)
• API - backend per integrazioni programmatiche
• Auth / Login - login
• Email delivery - email transazionali
• Background jobs - sync, fatturazione, exports
• Status page - meta stessa - anche questa può cadere (perciò dovrebbe essere ospitata su infrastruttura diversa dal prodotto)

Comunicazione di incident: anatomia di un buon update

Durante un outage reale segui queste fasi:

1. Investigating - "Abbiamo identificato un problema con [componente]. Il team indaga la causa." (entro 5 min dal rilevamento)
2. Identified - "La causa è [brevemente]. Stiamo lavorando al fix. ETA [tempo]." (quando sai cosa lo causa)
3. Monitoring - "Abbiamo deployato il fix. Monitoriamo se il problema non si ripresenta." (dopo il deploy della soluzione)
4. Resolved - "L'incident è risolto. Durata X minuti. Postmortem segue." (recovery confermato)

Ogni fase riceve timestamp e update. Dopo l'incident pubblica un post-mortem (root cause, timeline, cosa facciamo perché non si ripeta).

Regola: Non usare mai frasi vaghe come "experiencing some issues". I clienti vogliono concretezza: "Login fallisce per ~30% dei tentativi. API funziona normalmente. Web disponibile solo in modalità read-only."

Hosting: principio di infrastruttura indipendente

La status page deve girare su infrastruttura diversa dal servizio monitorato. Se la tua regione AWS cade, anche la tua status page ospitata sulla stessa regione AWS cade - esattamente quando i clienti ne hanno più bisogno.

Soluzioni pratiche:

• Hosting via SaaS esterno (StatusPage.io, ePulz.io, Better Stack, Statuspage)
• Propria pagina statica su CDN (Cloudflare Pages, Netlify) con endpoint API altrove
• Worst case: pagina statica minima su Cloudflare con testo aggiornato manualmente

Subscribers: e-mail / RSS / webhook

I clienti non vogliono rinfrescare ripetutamente la status page. Una buona pagina supporta:

• Email subscribers - in ePulz.io disponibile per utenti loggati con piano pagato (raccogliamo iscrizioni solo da account verificati, non da visitatori anonimi)
• RSS / Atom feed - modo tradizionale per tech-savvy users
• Webhook - per team che vogliono integrare nel proprio Slack o PagerDuty

Anti-pattern: nascondere problemi

La tentazione è grande di marcare un outage come "degraded" invece di "down", o di non mostrarlo affatto. Questo è miope:

• I clienti lo noteranno comunque (monitoraggio proprio, flow di support ticket, social network)
• Perdita di fiducia quando scoprono che il status dice "OK" durante un outage evidente
• Nessun quadro del vero trend uptime per le decisioni interne

Strategia migliore: trasparenza radicale. GitLab, Cloudflare, Stripe pubblicano tutti post-mortem dettagliati anche per errori imbarazzanti. La community lo apprezza.

SEO e brand

La status page dovrebbe:

• Essere su proprio sottodominio (status.example.com) o prefisso URL
• Avere proprio branding (logo, colori) - il cliente deve sapere di essere sulla tua pagina
• Essere indicizzata in Google (migliore visibilità nella ricerca "[brand] down")
• Linkata dalla pagina principale (footer "Stato del servizio")

Conclusione

La status page non è decorazione. È uno strumento operativo che riduce il costo del support durante un incident e costruisce fiducia a lungo termine. L'investimento di 1-2 ore nella configurazione corretta si ripaga al primo outage maggiore.

Crea una status page in 5 minuti

ePulz.io status pages con proprio branding, email subscribers e incident timeline. 7 giorni gratis.

Prova ePulz.io →