Come creare una status page: componenti, incidenti e controlli di uptime

Una status page indica ai tuoi utenti, in un unico posto, se il servizio funziona. Per costruirne una ti servono un elenco di componenti (sito web, API, pagamenti, invio email), lo stato attuale di ciascuno, gli incidenti con aggiornamenti datati, uno storico degli incidenti passati e, facoltativamente, le iscrizioni, così le persone vengono a sapere dei problemi senza doverli controllare. La pagina in sé è semplice. La decisione importante è dove viene eseguita: una status page deve restare online quando la tua app è giù, quindi non dovrebbe condividere hosting, database o pipeline di deploy con ciò che segnala.

A cosa serve una status page

Quando qualcosa si rompe, gli utenti vogliono sapere tre cose: è un problema solo mio, siete al corrente, e quando sarà risolto. Una status page risponde a tutte e tre senza una valanga di ticket di assistenza. Inoltre costruisce fiducia nel tempo, perché uno storico degli incidenti visibile, con resoconti onesti, mostra come gestisci i problemi.

Non è un changelog. Le nuove funzionalità vanno nella pagina del changelog; i disservizi e le manutenzioni vanno qui.

Cosa serve alla pagina

Dati

Gli stati dei componenti sono di solito un breve elenco fisso: Operativo, Prestazioni degradate, Interruzione parziale, Interruzione grave, In manutenzione.

Pagine

• Status page pubblica: un banner generale («Tutti i sistemi sono operativi» oppure lo stato peggiore attuale), ogni componente con il suo stato, eventuali incidenti attivi con i relativi aggiornamenti, le manutenzioni in programma e una striscia dello storico degli ultimi 90 giorni se hai dati di controllo.
• Pagina dell'incidente: cronologia completa degli aggiornamenti di un singolo incidente, con un proprio URL in modo che il supporto possa linkarlo.
• Storico: incidenti passati, raggruppati per mese.
• Iscrizione: registrazione via email con conferma e preferenze per componente.
• Amministrazione: creare un incidente, pubblicare aggiornamenti, cambiare lo stato dei componenti, programmare manutenzioni.

Permessi

Il pubblico vede tutto ciò che viene pubblicato. Solo il tuo team può pubblicare. Se possibile, tieni separato il login dell'amministrazione dal sistema di login della tua app principale, così un'interruzione del provider di autenticazione non ti blocca fuori dalla tua status page.

La decisione chiave: tenerla indipendente

È qui che fallisce la maggior parte delle status page fatte in casa. Se la tua status page:

• gira sullo stesso server o account di hosting della tua app,
• legge dallo stesso database,
• sta dietro la stessa configurazione di dominio o CDN,
• oppure viene rilasciata dalla stessa pipeline,

allora molti disservizi la metteranno giù insieme a tutto il resto, proprio quando le persone ne hanno bisogno. Passi pratici:

• Hosting separato. Un progetto o un provider diverso dall'app principale.
• Un sottodominio proprio, come status.esempio.com, puntato separatamente nel DNS. Vedi come funzionano domini e DNS.
• Dati propri. Gli incidenti stanno nello storage della status page, non nel database della tua app.
• Un fallback statico. Alcuni team rendono statica la pagina pubblica e la ricostruiscono a ogni aggiornamento, così c'è quasi nulla che possa rompersi.

Aggiornamenti manuali o controlli automatici

Manuali (da qui si parte)

Il tuo team pubblica gli incidenti e cambia gli stati dei componenti a mano dalla pagina di amministrazione. In pratica molte status page funzionano così, perché un giudizio umano («i pagamenti sono lenti per alcuni tipi di carta») è più utile di un pallino rosso automatico.

Per scoprire rapidamente i problemi, usa un servizio esterno di controllo dell'uptime che verifica la tua app ogni minuto circa e ti avvisa via email, SMS o chat. Molti servizi di monitoraggio hanno piani gratuiti.

Automatici

L'automazione significa che qualcosa controlla regolarmente ogni componente e aggiorna il suo stato. Serve codice che giri su una pianificazione, dall'esterno dell'infrastruttura della tua app principale. Due schemi comuni:

• Un monitor esterno chiama la tua status page tramite un webhook quando un controllo fallisce o torna a funzionare, e la status page aggiorna il componente.
• Un job pianificato nell'hosting della status page verifica ogni componente e registra il risultato. Controlla come il tuo hosting gestisce le attività pianificate prima di farci affidamento; la nostra guida su come eseguire job in background spiega le opzioni.

Gli stati automatici possono oscillare (su, giù, su) su una rete lenta. Richiedi due o tre controlli falliti prima di cambiare uno stato, e lascia che sia una persona a confermare prima di annunciare un disservizio grave.

Come scrivere gli aggiornamenti sugli incidenti

• Pubblica presto. «Stiamo indagando su segnalazioni di accessi non riusciti» entro pochi minuti vale più di un messaggio perfetto un'ora dopo.
• Di' cosa notano gli utenti, non cosa si è rotto internamente.
• Indica quando arriverà il prossimo aggiornamento, e mantienilo.
• Chiudi con un breve riepilogo una volta risolto: cosa è successo, per quanto tempo, cosa stai cambiando.

Un primo prompt che funziona

Costruisci una status page indipendente per la nostra app Parcelio, da ospitare separatamente su status.parcelio.com. Componenti: Sito web, API di tracciamento, Notifiche, Pagamenti, ognuno con stato Operativo, Prestazioni degradate, Interruzione parziale, Interruzione grave o In manutenzione. La pagina pubblica mostra un banner generale con lo stato peggiore attuale, ogni componente con il suo stato, gli incidenti attivi con aggiornamenti datati dal più recente, le manutenzioni in programma e un elenco degli incidenti passati raggruppati per mese. Ogni incidente ha una pagina propria. Aggiungi una pagina di amministrazione protetta da password per creare incidenti (titolo, impatto, componenti coinvolti), pubblicare aggiornamenti (messaggio e stato: Investigating, Identified, Monitoring, Resolved), cambiare lo stato dei componenti e programmare manutenzioni. Aggiungi un endpoint POST /api/check-result che accetta da un monitor esterno il nome di un componente e up/down, protetto da un token segreto, e segna un componente come Degradato solo dopo tre down consecutivi. Salva tutto nel database di questa app. Design semplice e tranquillo che si carica in fretta sul telefono.

Passi di costruzione

1. Pagina pubblica e amministrazione con incidenti manuali. Da sola è già una status page funzionante.
2. Ospitala separatamente e punta un sottodominio su di essa.
3. Pagine degli incidenti e storico.
4. Finestre di manutenzione.
5. Iscrizioni. Registrazione via email con doppia conferma e notifiche per i nuovi incidenti e aggiornamenti. L'email richiede un provider; vedi come inviare email dalla tua app.
6. Webhook del monitor se vuoi cambiamenti di stato automatici.
7. Fai una prova. Crea un incidente finto, pubblica aggiornamenti, risolvilo, controlla le email, poi eliminalo.

Errori comuni

• Ospitarla insieme all'app. L'errore più comune e più grave.
• Una pagina che dice sempre «Tutti i sistemi sono operativi». Se non mostra mai problemi, gli utenti smettono di fidarsi.
• Nessuna data o fuso orario. Mostra sempre gli orari con il fuso.
• Affidarsi al login della tua app principale per la pagina di amministrazione.
• Silenzio tra un aggiornamento e l'altro. «Nessuna novità, stiamo ancora lavorando» è un aggiornamento valido.
• Stati automatici instabili. Richiedi fallimenti ripetuti prima di un cambiamento.

Quando è meglio un servizio di status page già pronto

I servizi di status page ospitati nascono proprio per il problema dell'indipendenza: girano su infrastrutture separate, gestiscono le notifiche agli iscritti via email e SMS e spesso includono monitoraggio e integrazioni con gli strumenti di gestione degli incidenti. Se l'uptime fa parte di ciò che offri ai clienti, o hai obblighi contrattuali di segnalazione degli incidenti, un servizio dedicato di solito vale la spesa. Molti hanno piani gratuiti o a basso costo per piccoli team, quindi verifica prima di costruirne una.

Costruiscila da sola quando vuoi il pieno controllo di design e testi, quando le tue esigenze sono semplici (qualche componente, aggiornamenti manuali) o quando una status page fa parte di un prodotto che stai costruendo per altri.

Costruirla con Mythex

Su Mythex puoi costruire la status page come progetto a sé, separato dalla tua app principale, che ti dà hosting separato e un database proprio. Descrivila in chat, verificala nell'anteprima dal vivo, poi pubblicala e collega un sottodominio come status.tuodominio.com (i domini personalizzati sono disponibili nel piano Pro). Tieni presente che le app Mythex pubblicate e i loro database vanno in pausa quando sono inattivi e si riattivano alla visita successiva, quindi il primo caricamento dopo un periodo di calma può essere più lento; una pagina semplice e leggera aiuta.

Mythex non documenta le attività pianificate, quindi per i controlli automatici usa un monitor di uptime esterno che chiama un endpoint webhook nella tua status page (vedi la guida ai webhook). Le email di avviso agli iscritti passano dal tuo provider, con la chiave salvata come segreto del progetto (guida all'invio email).

Domande