Come funziona il monitoraggio dell'uptime dei siti web nel 2026

Un servizio che raggiunge il 99,99% di uptime resta offline per meno di 53 minuti all'anno. Se si scende al 99,9%, si perdono più di otto ore. Il monitoraggio dell'uptime è quel piccolo elemento di infrastruttura che individua quei minuti nel momento esatto in cui si verificano. Questa guida spiega come funziona, cosa monitorare, con quale frequenza controllare e gli errori che trasformano uno strumento utile in rumore di fondo.

Cosa fa effettivamente un monitor di uptime

Un monitor di uptime esegue un piccolo ciclo. Da un server collocato da qualche parte sulla rete internet pubblica, invia una richiesta a un bersaglio designato. Registra la risposta, il codice di stato e il tempo impiegato per il round trip. Poi attende l'intervallo scelto e riprova.

La sonda risiede volutamente al di fuori della tua infrastruttura. Se monitorassi dall'interno della tua stessa rete, non riusciresti a individuare i disservizi che sembrano funzionanti dall'interno ma che si interrompono per gli utenti reali. Questa è la differenza tra monitoraggio sintetico (un prober esterno) e monitoraggio degli utenti reali (telemetria proveniente dai visitatori reali). La maggior parte dei team utilizza entrambi. Il monitoraggio dell'uptime rappresenta il lato sintetico.

Cosa puoi effettivamente monitorare

Gli strumenti di uptime moderni coprono molto più del semplice HTTP. I nove tipi di sonde che si trovano sul mercato rispondono ognuno a una domanda leggermente diversa.

• HTTP restituisce un codice di stato e un tempo di risposta per qualsiasi URL.
• Ping (ICMP) verifica che un host risponda a livello di rete.
• SSL controlla quanti giorni mancano alla scadenza del certificato.
• DNS verifica che i record A, AAAA, MX, TXT o NS continuino a risolversi nei valori attesi.
• Porta TCP controlla se un servizio è in ascolto su una determinata porta, o se una porta che dovrebbe essere chiusa risulta improvvisamente aperta.
• WHOIS monitora la scadenza della registrazione del tuo nome di dominio.
• Blacklist verifica se il tuo IP di invio è finito su Spamhaus, SORBS o liste simili.
• Heartbeat inverte la relazione: è il tuo job a inviare un ping al monitor, e ricevi un avviso quando smette di farlo.

Con quale frequenza controllare

La frequenza dei controlli è un compromesso tra precisione e rumore. Una cadenza più rapida individua disservizi più brevi ma produce più falsi positivi causati da brevi interruzioni transitorie della rete. Una cadenza più lenta attenua il rumore ma trascura i brevi disservizi che incidono comunque sul tuo error budget.

Un valore predefinito pragmatico: 60 secondi per HTTP e ping sui servizi importanti, 5 minuti per le pagine a bassa priorità, 15 minuti per SSL, ogni ora per WHOIS. Scendi a 30 secondi solo per i servizi in cui ogni minuto di inattività ti costa concretamente in termini economici. Andare sotto i 30 secondi raramente migliora il risultato e spesso genera affaticamento da allerta.

Instradare gli avvisi senza generare rumore

Un avviso che nessuno legge è peggio di nessun avviso. Tre regole bastano per la maggior parte dei team.

• Per impostazione predefinita, invia gli avvisi DOWN su un unico canale, preferibilmente quello che il tuo team già consulta (Slack, Discord, Telegram o email).
• Usa una regola di soglia di almeno 3 fallimenti consecutivi prima di inviare un page. Un singolo controllo mancato è rumore. Tre di seguito sono un segnale.
• Instrada i servizi critici verso uno strumento di paging (PagerDuty, Opsgenie) tramite un webhook firmato. Instrada tutto il resto verso la chat. Conferma gli incidenti per fermare il pager una volta che un operatore se ne sta occupando.

Gli errori che uccidono i programmi di uptime

Il primo errore è monitorare solo la home page. Una home page funzionante non dice quasi nulla sul flusso di checkout o sull'API con cui dialoga la tua app mobile. Aggiungi monitor HTTP specifici per gli URL più importanti dal punto di vista del fatturato o del carico di supporto.

Il secondo errore è il fan-out silenzioso. Ogni monitor attiva ogni canale, poi ogni membro del team silenzia quelli più rumorosi e l'incidente reale finisce in un canale silenziato. Definisci un'unica rotta predefinita, instrada le eccezioni verso persone specifiche e rivedi le tue regole ogni trimestre.

Una configurazione iniziale di 10 minuti

Se stai partendo da zero, la sequenza pratica è breve. Crea un monitor HTTP sul tuo URL principale con un intervallo di 60 secondi. Crea un monitor SSL sullo stesso hostname con una finestra di preavviso di 30 giorni. Crea una regola di notifica che instradi gli avvisi DOWN sulla chat del tuo team. Aggiungi una pagina di stato se hai utenti esterni interessati all'uptime. Aggiungi heartbeat per i cron job che gestiscono fatturazione, report e backup. A questo punto sei già davanti all'operatore medio.