Impara come pianificare, costruire e pubblicare una pagina di status SaaS con cronologia degli incidenti, messaggi chiari e iscrizioni in modo che i clienti restino informati durante i blackout.
Una pagina di stato SaaS è un sito pubblico (o riservato ai clienti) che mostra se il tuo prodotto sta funzionando in questo momento — e cosa stai facendo se non lo è. Diventa la fonte unica di verità durante gli incidenti, separata dai social, dai ticket di supporto e dai rumor.
Aiuta più persone di quanto potresti aspettarti:
Un buon sito di stato di servizio di solito contiene tre livelli correlati (ma diversi):
L'obiettivo è chiarezza: lo stato in tempo reale risponde a “Posso usare il prodotto?” mentre la cronologia risponde a “Quanto spesso succede?” e i postmortem rispondono a “Perché è successo e cosa è cambiato?”.
Una pagina di stato funziona quando gli aggiornamenti sono veloci, in linguaggio semplice e onesti sull'impatto. Non serve una diagnosi perfetta per comunicare. Ti servono invece timestamp, ambito (chi è interessato) e l'ora del prossimo aggiornamento.
Ti servirà durante interruzioni, prestazioni degradate (login lenti, webhook ritardati) e manutenzioni programmate che possono causare brevi interruzioni o rischi.
Se tratti la pagina di stato come una superficie di prodotto (non come una pagina operativa fatta al volo), il resto della configurazione diventa molto più semplice: puoi definire owner, costruire template e connettere il monitoring senza reinventare il processo a ogni incidente.
Prima di scegliere uno strumento o progettare un layout, decidi cosa deve fare la tua pagina di stato. Un obiettivo chiaro e un owner esplicito sono ciò che mantiene la pagina utile durante un incidente — quando tutti sono occupati e l'informazione è confusa.
La maggior parte dei team SaaS crea una pagina di stato per tre risultati pratici:
Annota 2–3 segnali misurabili che puoi monitorare dopo il lancio: meno ticket duplicati durante gli incidenti, tempo più veloce al primo aggiornamento, o più clienti che usano le iscrizioni.
Il tuo lettore principale è solitamente un cliente non tecnico che vuole sapere:
Questo significa minimizzare il gergo. Preferisci “Alcuni clienti non riescono ad accedere” a “Tassi 5xx elevati su auth.” Se servono dettagli tecnici, mettili come una frase secondaria e breve.
Scegli un tono che puoi mantenere sotto pressione: calmo, fattuale e trasparente. Decidi in anticipo:
Rendi l'ownership esplicita: la pagina di stato non dovrebbe essere “compito di tutti”, altrimenti diventa di nessuno.
Hai due opzioni comuni:
Se la tua app principale può cadere, un sito di status standalone è solitamente più sicuro. Puoi comunque linkarlo in modo prominente dall'app e dal centro assistenza (ad esempio, /help).
Una pagina di stato è utile quanto la “mappa” che la sostiene. Prima di scegliere colori o scrivere copy, decidi su cosa stai effettivamente riportando. L'obiettivo è riflettere come i clienti vivono il prodotto — non come è organizzata la tua org.
Elenca le parti che un cliente potrebbe descrivere quando dice “è rotto”. Per molti prodotti SaaS, un set pratico di partenza è:
Se offri più regioni o tier, cattura anche quelli (es. “API – US” e “API – EU”). Usa nomi comprensibili per i clienti: “Login” è più chiaro di “IdP Gateway”.
Scegli un raggruppamento che corrisponda al modo in cui i clienti pensano al tuo servizio:
Evita liste infinite. Se hai decine di integrazioni, considera un componente genitore (“Integrazioni”) più alcuni figli ad alto impatto (es. “Salesforce”, “Webhooks”).
Un modello semplice e coerente evita confusione durante gli incidenti. Livelli comuni includono:
Scrivi criteri interni per ogni livello (anche se non li pubblichi). Per esempio, “Partial Outage = una regione giù” o “Degraded = p95 latency sopra X per Y minuti.” La coerenza costruisce fiducia.
La maggior parte delle interruzioni coinvolge terze parti: hosting cloud, delivery email, processori di pagamento o identity provider. Documenta queste dipendenze così i tuoi aggiornamenti possono essere accurati.
Se mostrarle pubblicamente dipende dal tuo pubblico. Se i clienti possono essere direttamente impattati (es. pagamenti), mostrare una dipendenza può essere utile. Se crea rumore o invita a giochi di colpe, mantieni le dipendenze interne ma riferiscile negli aggiornamenti quando rilevante (es. “Stiamo investigando errori elevati dal nostro provider di pagamenti”).
Una volta definito questo modello di componenti, il resto della configurazione della pagina di stato diventa molto più semplice: ogni incidente avrà subito un “dove” (componente) e “quanto è grave” (stato).
Una pagina di stato è più utile quando risponde alle domande del cliente in pochi secondi. Le persone arrivano spesso stressate e vogliono chiarezza — non molta navigazione.
Dai priorità all'essenziale in cima:
Scrivi in linguaggio semplice. “Tassi di errore elevati sulle richieste API” è più chiaro di “Partial outage in upstream dependency.” Se devi usare termini tecnici, aggiungi una breve traduzione (“Alcune richieste potrebbero non rispondere o andare in timeout”).
Un pattern affidabile è:
Per la lista dei componenti, mantieni le etichette orientate al cliente. Se il tuo servizio interno si chiama “k8s-cluster-2”, i clienti probabilmente hanno bisogno di “API” o “Background Jobs”.
Rendi la pagina leggibile sotto pressione:
Posiziona un piccolo set di link in cima (header o subito sotto il banner):
L'obiettivo è fiducia: i clienti devono capire subito cosa succede, cosa è impattato e quando riceveranno il prossimo aggiornamento.
Quando scatta un incidente, il tuo team sta contemporaneamente diagnosticando, mitigando e rispondendo alle domande dei clienti. I template rimuovono l'incertezza così gli aggiornamenti restano coerenti, chiari e rapidi — soprattutto quando persone diverse potrebbero pubblicare.
Un buon aggiornamento inizia sempre con gli stessi fatti di base. Al minimo, standardizza questi campi così i clienti capiscono immediatamente cosa succede:
Se pubblichi una pagina di cronologia degli incidenti, mantenere questi campi coerenti rende gli incidenti passati facili da scorrere e confrontare.
Punta a aggiornamenti brevi che rispondono alle stesse domande ogni volta. Ecco un template pratico che puoi copiare nel tuo strumento di status:
Titolo: Sommario breve e specifico (es. “Errori API per la regione EU”)\n\nOra d'inizio: YYYY-MM-DD HH:MM (TZ)\n\nComponenti interessati: API, Dashboard, Payments\n\nImpatto: Cosa vedono gli utenti (errori, timeout, prestazioni degradate) e chi è interessato\n\nCosa sappiamo: Una frase sulla causa se confermata (evita speculazioni)\n\nCosa stiamo facendo: Azioni concrete (rollback, scalare, escalation al vendor)\n\nProssimo aggiornamento: Ora in cui pubblicherai di nuovo\n\nAggiornamenti:\n\n- HH:MM (TZ) — Investigating: …\n- HH:MM (TZ) — Identified: …\n- HH:MM (TZ) — Monitoring: …\n- HH:MM (TZ) — Resolved: …
I clienti non vogliono solo informazioni — vogliono prevedibilità.
La manutenzione programmata dovrebbe apparire calma e strutturata. Standardizza i post di manutenzione con:
Mantieni il linguaggio specifico (cosa cambia, cosa noteranno gli utenti) e evita promesse eccessive — i clienti apprezzano la precisione più dell'ottimismo.
Una pagina di cronologia degli incidenti è più di un log — è un modo per clienti (e il tuo team) di capire rapidamente quanto spesso succedono problemi, quali tipologie si ripetono e come rispondete.
Una cronologia chiara costruisce fiducia tramite trasparenza. Crea anche visibilità sui trend: se vedi ricorrenti incidenti di “latency API” ogni poche settimane, è un segnale per investire in lavoro di performance (e per dare priorità al processo di post-incident review). Nel tempo, report coerenti possono ridurre i ticket perché i clienti trovano le risposte da soli.
Scegli una finestra di retention che corrisponda alle aspettative dei clienti e alla maturità del prodotto.
Qualunque sia la scelta, dichiarala chiaramente (es. “La cronologia degli incidenti è conservata per 12 mesi”).
La coerenza rende la scansione facile. Usa un formato di nome prevedibile come:
YYYY-MM-DD — Breve sommario (es. “2025-10-14 — Consegna email ritardata”)
Per ogni incidente mostra almeno:
Se pubblichi postmortem, collega dalla pagina di dettaglio dell'incidente al resoconto (per esempio: “Leggi il postmortem” collegato a /blog/postmortems/2025-10-14-email-delays). Questo mantiene la timeline pulita offrendo comunque dettaglio a chi lo desidera.
Una pagina di stato è utile quando i clienti pensano di verificarla. Le iscrizioni ribaltano il paradigma: i clienti ricevono aggiornamenti automaticamente, senza ricaricare la pagina o scrivere al supporto per conferma.
La maggior parte dei team offre almeno alcune opzioni:
Se supporti più canali, mantieni il flusso di iscrizione coerente così i clienti non avranno l'impressione di doversi iscrivere quattro volte.
Le iscrizioni devono essere sempre opt-in. Sii esplicito su cosa riceveranno prima della conferma — specialmente per gli SMS.
Dai ai sottoscrittori controllo su:
Queste preferenze riducono l'alert fatigue e mantengono le tue notifiche affidabili. Se non hai ancora subscriptions per componente, inizia con “Tutti gli aggiornamenti” e aggiungi filtri dopo.
Durante un incidente, il volume di messaggi schizza e i provider terzi possono limitare il traffico. Verifica:
Vale la pena eseguire un test programmato (anche trimestrale) per assicurarsi che le iscrizioni funzionino ancora come previsto.
Aggiungi un callout chiaro nella homepage di status — sopra la piega se possibile — così i clienti possono iscriversi prima del prossimo incidente. Rendilo visibile su mobile e includilo nei posti dove i clienti cercano aiuto (come un link dal tuo portale di supporto o dal /help).
Scegliere come costruire la pagina di status riguarda meno il “possiamo farlo?” e più il cosa vuoi ottimizzare: rapidità di lancio, affidabilità durante gli incidenti e sforzo di manutenzione.
Uno strumento hosted è di solito il percorso più veloce. Ottieni una pagina di status pronta, iscrizioni, timeline degli incidenti e spesso integrazioni con sistemi di monitoring comuni.
Cosa cercare in uno strumento hosted:
Il DIY può essere ottimo se vuoi controllo totale su design, retention dei dati e presentazione della cronologia degli incidenti. Il compromesso è che tu possiedi affidabilità e operazioni.
Un'architettura DIY pratica è:
Se ti autohosti, pianifica i failure mode: cosa succede se il tuo database primario non è disponibile o la pipeline di deploy è giù? Molti team tengono la pagina di status su infrastruttura separata (o anche un provider diverso) rispetto al prodotto principale.
Se vuoi il controllo del DIY senza ricostruire tutto, una piattaforma vibe-coding come Koder.ai può aiutarti a mettere su un sito di status personalizzato (UI web più una piccola API per gli incidenti) rapidamente da una specifica generata in chat. Questo è particolarmente utile per team che vogliono modelli di componenti su misura, una UX di cronologia incidenti custom o workflow amministrativi interni — pur potendo esportare il codice, deployare e iterare velocemente.
Gli strumenti hosted hanno prezzi mensili prevedibili; il DIY richiede tempo ingegneristico, costi di hosting/CDN e manutenzione continua. Se stai confrontando opzioni, delinea la spesa mensile prevista e il tempo interno richiesto — poi verifica con il budget (vedi /pricing).
Una pagina di stato è utile solo se riflette la realtà rapidamente. Il modo più semplice è collegare i sistemi che rilevano i problemi (monitoring) con quelli che coordinano la risposta (incident workflow), così gli aggiornamenti sono coerenti e tempestivi.
La maggior parte dei team combina tre fonti di dati:
Una regola pratica: il monitoring rileva; l'incident workflow coordina; la pagina di stato comunica.
L'automazione può risparmiare minuti quando conta:
Mantieni il primo messaggio pubblico conservativo. “Investigating elevated errors” è più sicuro di “Outage confirmed” quando stai ancora validando.
La messaggistica totalmente automatica può ritorcersi contro:
Usa l'automazione per bozzare e suggerire aggiornamenti, ma richiedi una review umana per il linguaggio rivolto ai clienti — specialmente per gli stati Identified, Mitigated e Resolved.
Tratta la pagina di stato come un registro pubblico. Assicurati di poter rispondere a:
Questa traccia aiuta la post-incident review, riduce la confusione durante i passaggi di consegne e costruisce fiducia quando i clienti chiedono chiarimenti.
Una pagina di stato serve solo se è raggiungibile quando il tuo prodotto non lo è. Il difetto più comune è costruire la pagina di status sulla stessa infrastruttura dell'app — così quando l'app cade, sparisce anche la pagina di status, lasciando i clienti senza fonte di verità.
Quando possibile, ospita la pagina di status su un provider diverso rispetto all'app di produzione (o almeno in una regione/account differente). L'obiettivo è separare il raggio d'azione: un outage nella piattaforma dell'app non dovrebbe portare giù anche le comunicazioni sugli incidenti.
Considera anche di separare il DNS. Se il DNS del dominio principale è gestito nello stesso posto dell'edge/CDN dell'app, un problema DNS o di certificato può bloccare entrambi. Molti team usano un sottodominio dedicato (per esempio, status.yourcompany.com) con DNS ospitato indipendentemente.
Mantieni le risorse leggere: JavaScript minimo, CSS compresso e nessuna dipendenza che richieda le API della tua app per il rendering. Metti una CDN davanti alla pagina di status e abilita caching per le risorse statiche così si carica anche sotto traffico elevato durante gli incidenti.
Un buon piano di sicurezza è una modalità statica di fallback:
I clienti non dovrebbero dover effettuare il login per vedere lo stato del servizio. Mantieni la pagina pubblica, ma metti gli strumenti di amministrazione/editor dietro autenticazione (SSO se disponibile), con controlli di accesso forti e audit log.
Infine, testa gli scenari di failure: blocca temporaneamente l'origine dell'app in un ambiente di staging e conferma che la pagina di status si risolve, si carica velocemente e può essere aggiornata quando serve di più.
Una pagina di stato costruisce fiducia solo se aggiornata consistentemente durante incidenti reali. Quella coerenza non accade per caso — ti servono ownership chiara, regole semplici e una cadenza prevedibile.
Tieni il team centrale piccolo ed esplicito:
Se siete un team piccolo, una persona può ricoprire due ruoli — l'importante è decidere in anticipo. Documenta i passaggi di responsabilità e i percorsi di escalation nel tuo manuale on-call (vedi /docs/on-call).
Quando un alert diventa un incidente con impatto cliente, segui un flusso ripetibile:
Una regola pratica: posta il primo aggiornamento entro 10–15 minuti, poi ogni 30–60 minuti finché l'impatto continua — anche se il messaggio è “Nessun cambiamento, ancora in investigazione.”
Entro 1–3 giorni lavorativi, fai una post-incident review leggera:
Poi aggiorna l'entry dell'incidente con il sommario finale così la cronologia rimane utile — non solo un registro di messaggi “risolto”.
Una pagina di stato è utile solo se è facile da trovare, da fidarsi e aggiornata con costanza. Prima di annunciarla, fai un rapido controllo “production-ready” — e poi stabilisci una cadenza leggera per migliorarla nel tempo.
Copy e struttura
Branding e fiducia
Accessi e permessi
Test del workflow completo
Annuncio
Se stai costruendo il tuo sito di status, considera di eseguire la stessa checklist in staging prima. Strumenti come Koder.ai possono accelerare questo ciclo di iterazione generando UI web, schermate admin e endpoint backend da una singola specifica — poi permettendoti di esportare il codice e deployare dove preferisci.
Monitora pochi risultati semplici e rivedili mensilmente:
Tieni una tassonomia di base così la cronologia diventa azionabile:
Col tempo, piccoli miglioramenti — wording più chiaro, aggiornamenti più rapidi, migliore categorizzazione — si sommano in meno interruzioni, meno ticket e più fiducia dei clienti.
Una pagina di stato SaaS è una pagina dedicata che mostra lo stato corrente del servizio e gli aggiornamenti sugli incidenti in un unico luogo canonico. È importante perché riduce il carico di richieste “È giù?” al supporto, definisce le aspettative durante i guasti e costruisce fiducia grazie a comunicazioni chiare e con timestamp.
Lo stato in tempo reale risponde a “Posso usare il prodotto adesso?” con stati a livello di componente.
La cronologia degli incidenti risponde a “Quanto spesso succede?” mostrando una timeline di incidenti e manutenzioni passate.
I postmortem rispondono a “Perché è successo e cosa è cambiato?” con causa radice e azioni preventive (spesso collegati dall'entry dell'incidente).
Parti da 2–3 risultati misurabili:
Annota questi obiettivi e riesaminali mensilmente così la pagina non diventa obsoleta.
Assegna un proprietario esplicito e un backup (spesso la rotazione on-call). Molte squadre usano:
Definisci anche regole in anticipo: chi può pubblicare, se servono approvazioni e la cadenza minima degli aggiornamenti (ad esempio, ogni 30–60 minuti durante incidenti gravi).
Scegli i componenti in base a come i clienti descrivono i problemi, non ai nomi dei servizi interni. Componenti comuni includono:
Se l'affidabilità varia per geografia, separa per regione (ad esempio, “API – US” e “API – EU”).
Usa un set piccolo e coerente di livelli e documenta i criteri interni per ciascuno:
La coerenza è più importante della precisione assoluta. I clienti devono imparare cosa significa ogni livello grazie a un uso ripetuto e prevedibile.
Un aggiornamento pratico per un incidente dovrebbe sempre includere:
Anche se non conosci ancora la causa radice, puoi comunque comunicare ambito, impatto e cosa stai facendo dopo.
Pubblica un primo aggiornamento “Investigating” rapidamente (spesso entro 10–15 minuti dall'impatto confermato). Poi:
Se non puoi rispettare la cadenza, posta una breve nota che reimposta le aspettative invece di restare in silenzio.
Gli strumenti hosted ottimizzano velocità e affidabilità (spesso restano online anche se la tua app è giù) e solitamente includono iscrizioni e integrazioni.
Il DIY dà pieno controllo ma devi progettare la resilienza:
Offri i canali che i clienti già usano (comunemente email e SMS, più Slack/Teams o RSS). Mantieni le iscrizioni opt-in e chiarisci:
Testa la deliverability e i limiti di invio periodicamente così le notifiche funzionino quando il traffico aumenta durante un incidente.
