Pubblichiamo l'uptime reale per servizio ogni mese su una status page consultabile dal cliente. Se scendiamo sotto la soglia SLA, viene accreditata una quota del canone automaticamente — senza aspettare che ce lo chiediate. Misurazione con synthetic check esterni (non le nostre metriche interne: sono terzi) + Prometheus+Grafana per diagnostica. Retention metrica 12+ mesi.
01Uptime promesso vs uptime misurato
"Garantiamo il 99,9% di uptime" è una frase che si trova in ogni contratto di hosting, cloud o managed service. La domanda seria, però, non è quale numero è scritto, ma chi lo misura, dove viene pubblicato, cosa succede se non viene rispettato. In un contratto tipo, nessuna delle tre ha risposta chiara.
Uptime promesso: una clausola. Serve al commerciale per chiudere, serve all'ufficio acquisti per spuntare una casella. A fine anno nessuno va a controllare davvero quante ore il servizio è stato giù, perché non esiste una fonte condivisa e incontestabile.
Uptime misurato: un numero che si calcola ogni mese, viene pubblicato in un posto pubblico, e produce conseguenze contrattuali automatiche se va sotto soglia. Non richiede fiducia, richiede un meccanismo. La differenza è tutta qui.
02Come si calcola, tecnicamente
La formula è banale: tempo disponibile / tempo totale del periodo, espresso in percentuale. Un mese ha circa 43.200 minuti; al 99,9% puoi essere giù circa 43 minuti al mese, al 99,95% circa 22 minuti, al 99,99% circa 4 minuti. Quello che non è banale è cosa conta come downtime.
Regole che applichiamo:
- Il servizio è considerato giù se il synthetic check esterno riceve errore o timeout per almeno due rilevazioni consecutive da sonde diverse. Un blip isolato da una singola sonda non conta — è rumore di rete lato sonda, non disservizio vero.
- La finestra di downtime inizia al primo fail della seconda rilevazione e termina al primo check tornato verde.
- Degrado prestazionale (risposta lenta ma non errore) viene tracciato separatamente come incident di performance, non come downtime puro. È trasparente nel report, ma non entra nel calcolo SLA.
- Manutenzione pianificata e comunicata con almeno 72 ore di preavviso in finestra notturna non conta come downtime. Manutenzione di emergenza non pianificata sì.
03Gli strumenti
Tre livelli di osservazione, ognuno con un ruolo diverso.
Synthetic check esterni: sonde distribuite su provider terzi, esterne alla nostra infrastruttura, che ogni minuto fanno una richiesta HTTP al servizio e ne registrano stato e latenza. Sono la fonte ufficiale per il calcolo dell'uptime. Sono esterne apposta: se la misura fosse interna, in caso di problema di rete nostra il monitoring risulterebbe giù insieme al servizio e non registrerebbe il disservizio correttamente. Terzi ci obbligano all'onestà.
Prometheus + Grafana: metrica interna dettagliata — CPU, memoria, I/O, latenze applicative, coda job. Serve per diagnosticare cosa è successo, non per calcolare l'uptime. Retention storica 12+ mesi, così un incident può essere riletto anche a distanza di mesi.
Incident timeline: ogni evento sopra soglia genera un record con orario inizio, orario fine, causa probabile, azioni intraprese, post-mortem se rilevante. Entra nella status page pubblica in forma sintetica e nel report mensile in forma completa.
04La status page pubblica
Ogni cliente ha una status page accessibile via URL dedicato, consultabile con login o pubblica a seconda del contratto. Cosa pubblichiamo:
- Stato corrente di ogni servizio monitorato (verde / degradato / giù).
- Uptime degli ultimi 30 / 90 / 365 giorni, per servizio.
- Timeline incident degli ultimi 90 giorni con durata, impatto e breve descrizione causa.
- Manutenzioni pianificate, con finestra e servizi coinvolti.
Cosa non pubblichiamo: dettagli interni di architettura, IP, nomi host, versioni software, log applicativi. Una status page non è un leak — è un contratto di trasparenza sul risultato, non un'esposizione del come.
05Credit automatico quando sforiamo
Il meccanismo che rende il numero serio, invece che decorativo. Il contratto prevede soglie a gradini: se l'uptime mensile di un servizio coperto scende sotto la soglia SLA, il canone di quel servizio per il mese in corso viene decurtato di una quota proporzionale. Più scende, più alto il credit.
Due dettagli che cambiano tutto:
- Automatico: il credit viene applicato in fattura senza che il cliente debba aprire un ticket, mandare una PEC, provare che il downtime c'è stato. È il nostro sistema di billing a leggere la status page e applicarlo. Se il meccanismo non scatta, è un bug nostro.
- Cumulativo: tre incident piccoli nello stesso mese si sommano. Non esiste il trucco "sono stati tutti sotto la soglia singola quindi non contano".
È il tipo di clausola che nessuno scrive volentieri, perché allinea gli interessi: per guadagnarci davvero devi stare sopra soglia, non sotto. Scritta così, smette di essere una promessa e diventa un incentivo economico.
06Perché non promettiamo 99,999%
Onestà sugli ordini di grandezza. Il "five nines" — 99,999% — significa circa 5 minuti di downtime all'anno, per tutto lo stack. Lo raggiungono operatori iperscalari con ridondanza geografica attiva-attiva, team 24/7 multi-turno su un singolo servizio, investimenti che nessuna PMI italiana può assorbire e nessun managed provider onesto può promettere a mercato ragionevole.
Quello che è ottenibile, e che facciamo: 99,9% per servizi standard, 99,95% per infrastrutture progettate con ridondanza attiva. Sono numeri veri, sostenibili, misurabili. Promettere di più a chi non ha l'infrastruttura per pagarlo è marketing, non ingegneria.
07Esempio di report mensile
Ogni primo del mese il cliente riceve (e trova sulla status page) un report sintetico. Struttura tipo:
- Riepilogo uptime per servizio: percentuale misurata, soglia contrattuale, delta.
- Elenco incident del mese: data/ora, durata in minuti, servizio impattato, causa radice, azione correttiva.
- Indicatore credit: se c'è stata violazione di soglia, importo accreditato in fattura di fine mese.
- Manutenzioni effettuate: data, finestra, servizi toccati.
- Sezione capacity: trend risorse (CPU, storage, banda) con eventuali raccomandazioni.
È pensato per essere leggibile in tre minuti dal referente tecnico e in un minuto dal direttore. Due livelli di lettura, stesso documento.
08Come leggere la status page
Due semafori verdi non sono il dato importante. Quello che conta è:
- La media a 365 giorni, non quella a 30. Un mese pulito è normale, un anno pulito è un indicatore reale. Guardare solo l'ultimo mese incoraggia a nascondere i mesi brutti; guardare l'anno espone il trend.
- La distribuzione degli incident: un unico downtime da 40 minuti e quaranta downtime da un minuto producono lo stesso "99,9%" ma raccontano due servizi molto diversi. Cercate la granularità.
- La coerenza tra incident timeline e credit: se vedete un incident sopra soglia e non c'è il credit corrispondente, qualcosa non quadra. Chiedete.
In sintesi: la status page è un documento da interrogare, non da ammirare. Se nessuno la apre mai, tanto vale non averla — e chi la pubblica lo sa, ed è per questo che è un filtro di serietà.