Com'è fatta una buona pagina di stato pubblica

Una pagina di stato pubblica è il luogo a cui i clienti si rivolgono durante un disservizio. Una buona pagina di stato riduce il numero di ticket di supporto e costruisce fiducia. Da cosa è composta.

Cosa deve avere una buona pagina di stato

Lo stato attuale di ogni servizio chiave. Non solo "tutto OK", ma suddiviso per componenti (API, web, dashboard, emailing, payment processing).
Lo storico degli incidenti degli ultimi 90 giorni. Senza cercare di nascondere nulla - uno storico trasparente costruisce fiducia.
Una metrica di uptime (tipicamente su 30 giorni) per ogni componente, espressa come percentuale trasparente.
Manutenzione programmata. Un banner con la data e una descrizione di ciò che non sarà disponibile.
Incidente attivo con una timeline degli aggiornamenti. Investigating → Identified → Monitoring → Resolved.
Un modulo di iscrizione. I clienti ricevono un'email quando lo stato cambia e non devono controllare la pagina ripetutamente.

Una gerarchia di componenti chiara

Invece di un'unica voce "monitor", suddividi il servizio in componenti che abbiano senso dal punto di vista del cliente:

Web App - frontend (usato dai visitatori)
API - backend per le integrazioni programmatiche
Auth / Login - accesso
Email delivery - email transazionali
Background jobs - sync, fatturazione, export
Status page - componente meta: anche la pagina di stato stessa può andare giù (per questo dovrebbe girare su un'infrastruttura diversa da quella del prodotto)

Incident communication: anatomia di un buon aggiornamento

Durante un disservizio reale, rispetta queste fasi:

Investigating - "Abbiamo identificato un problema con [componente]. Il team sta indagando sulla causa." (entro 5 min dalla rilevazione)
Identified - "La causa è [in breve]. Stiamo lavorando a una correzione. ETA [orario]." (quando sai cosa causa il problema)
Monitoring - "Abbiamo rilasciato una correzione. Stiamo monitorando per assicurarci che il problema non si ripeta." (dopo il deployment della soluzione)
Resolved - "L'incidente è risolto. Durata X minuti. Seguirà un postmortem." (dopo il ripristino confermato)

Ogni fase riceve un timestamp e un proprio aggiornamento. Dopo l'incidente, pubblica un post-mortem (root cause, timeline e misure che prevengono il ripetersi).

Regola: Non usare mai frasi vaghe del tipo "experiencing some issues". I clienti vogliono concretezza: "Il login fallisce in ~30 % dei tentativi. L'API funziona normalmente. Il web è disponibile solo in modalità read-only."

Hosting: il principio dell'infrastruttura indipendente

La pagina di stato deve girare su un'infrastruttura diversa da quella del servizio monitorato. Se la tua regione AWS va giù, una pagina di stato ospitata nella stessa regione va giù con essa - proprio nel momento in cui i clienti ne hanno più bisogno.

Soluzioni pratiche:

Hosting tramite un SaaS esterno (ePulz.io, Better Stack, Atlassian Statuspage)
Una tua pagina statica su un CDN (Cloudflare Pages, Netlify) con l'endpoint API altrove
In casi estremi, una pagina statica minima su Cloudflare con testo aggiornato manualmente

Subscribers: email e webhook

I clienti non vogliono aggiornare di continuo la pagina di stato. Una buona pagina quindi supporta:

Email subscribers - in ePulz.io disponibile per gli utenti autenticati con un piano a pagamento (raccogliamo iscrizioni solo da account verificati, non da visitatori anonimi)
Webhook - per i team che vogliono integrare lo stato nel proprio Slack o PagerDuty

Anti-pattern: nascondere i problemi

La tentazione di contrassegnare un disservizio come "degraded" anziché "down" (o di non mostrarlo affatto) è forte, ma miope:

I clienti noteranno comunque il disservizio (tramite il proprio monitoring, i ticket di supporto o i social)
Perdi fiducia quando scoprono che lo stato segnala "OK" durante un disservizio evidente
Perdi l'immagine reale del trend di uptime, che ti serve per le decisioni interne

La strategia migliore è la trasparenza radicale. GitLab, Cloudflare e Stripe pubblicano post-mortem dettagliati anche per errori imbarazzanti, e la community lo apprezza.

SEO e brand

Una pagina di stato dovrebbe:

Trovarsi su un URL stabile e facile da ricordare per lo stato del servizio
Avere un proprio branding (logo, colori) - il cliente deve vedere che è ancora sulla tua pagina
Essere indicizzata su Google (migliore visibilità nella ricerca "[brand] down")
Essere collegata dalla pagina principale (footer "Stato del servizio")

Conclusione

Una pagina di stato non è decorazione. È uno strumento operativo che durante un incidente riduce il carico del supporto e costruisce fiducia nel lungo periodo. Investire qualche ora in una configurazione corretta si ripaga già al primo disservizio importante.

Crea una pagina di stato in 5 minuti

Pagine di stato ePulz.io con branding personalizzato, email subscribers e incident timeline. 7 giorni gratis.

Prova ePulz.io →