Per ridurre i falsi allarmi nel monitoraggio uptime, conferma ogni guasto con un secondo controllo prima di avvisare, imposta timeout in linea con il comportamento normale del sito, verifica un codice di stato e un contenuto attesi su un URL che rifletta davvero il servizio, indirizza gli avvisi di ogni monitor solo a chi può intervenire, inserisci i lavori programmati in una finestra di manutenzione annunciandoli e rivedi ogni mese i monitor più rumorosi. La maggior parte dei falsi allarmi nasce da una manciata di monitor con una di queste impostazioni sbagliata, quindi correggerli di solito è rapido.
Questa guida spiega perché i falsi allarmi sono pericolosi, da dove nascono e cosa cambiare, impostazione per impostazione.
Perché i falsi allarmi sono peggio di quanto sembri
Un falso allarme è un piccolo fastidio. Un flusso costante di falsi allarmi è alert fatigue: le persone silenziano il canale, filtrano le email in una cartella o danno un’occhiata al telefono e tornano a dormire. Il monitoraggio continua a girare, ma nessuno ascolta più. Il primo vero disservizio dopo quel momento viene scoperto alla vecchia maniera: da un cliente.
C’è anche un costo meno visibile. Ogni falso allarme distoglie qualcuno dal proprio lavoro per controllare un sito che funziona. In un mese si accumulano ore di concentrazione persa e un team che si fida meno dei propri strumenti. L’obiettivo non è avere meno avvisi fine a sé stesso, ma avere avvisi che valga la pena leggere ogni singola volta.
Da dove nascono i falsi allarmi
Interruzioni di rete momentanee tra una località di controllo e il tuo server: un pacchetto perso, un percorso lento, un breve intoppo DNS.
Timeout troppo stretti per una pagina a volte lenta ma funzionante.
L’aspettativa sbagliata: un controllo che vuole lo stato 200 da un URL che fa redirect, o che cerca un testo cambiato con un restyling.
L’URL sbagliato: una pagina dietro rate limiting, protezione anti-bot o login, oppure un server di staging spento di notte.
Lavori programmati: deploy e manutenzioni che mettono offline un sito di proposito.
Instradamento sbagliato: un avviso tecnicamente corretto ma inviato a qualcuno che non può farci nulla. Per quella persona è solo rumore.
Conferma ogni guasto con un secondo controllo
È la correzione più efficace in assoluto. Quando un controllo fallisce, ricontrolla prima di fare qualsiasi altra cosa. Un pacchetto perso o un breve intoppo superano il secondo controllo; un vero disservizio lo fallisce di nuovo. Solo un guasto confermato apre un incidente. Così sparisce gran parte delle interruzioni momentanee, senza ritardare gli avvisi reali di più di qualche secondo.
I servizi che controllano da più località possono eseguire il secondo controllo da un altro luogo, il che ti dice anche qualcosa di utile quando le località restano in disaccordo più a lungo. Se il tuo sito non risponde da un continente e funziona da un altro, il problema è probabilmente nell’instradamento o in un edge della CDN, non nel tuo server. Uptimecheck controlla da Stoccolma, Londra e New York, e conferma ogni guasto da una seconda località prima di aprire un incidente, così una singola interruzione momentanea non fa scattare nessun avviso; la pagina sul monitoraggio uptime spiega il flusso. Per le basi su come i controlli diventano avvisi, leggi che cos’è il monitoraggio uptime.
Imposta timeout realistici
Il timeout è il tempo che un controllo attende prima di considerare il sito offline. Se è troppo stretto, la normale variabilità diventa un disservizio. Se è troppo largo, un sito che impiega 40 secondi a rispondere risulta online.
Osserva lo storico dei tempi di risposta per qualche settimana. Annota l’intervallo normale e le risposte normali più lente.
Imposta il timeout con un buon margine sopra la risposta normale più lenta, ma sotto la soglia in cui i visitatori rinunciano.
Tratta la lentezza come un segnale a sé. Una pagina passata da 300 ms a 4 secondi va sistemata, ma in orario di lavoro, non con un avviso di disservizio nel cuore della notte.
Se una pagina è spesso vicina al timeout, il problema non è il monitor. È la pagina.
Aspettati il codice di stato e il contenuto giusti
Molti falsi allarmi nascono da controlli che si aspettano la cosa sbagliata:
Redirect. Monitorare http://northwind.shop quando il sito fa redirect a https://www.northwind.shop/ aggiunge un passaggio che può fallire per conto suo. Monitora direttamente l’URL finale e, se vuoi verificare il redirect, dagli un monitor dedicato.
Controlli sul contenuto fragili. Verificare un titolo di marketing si rompe al prossimo cambio dei testi. Scegli qualcosa di stabile che compaia solo quando la pagina funziona, come il nome dell’azienda nel footer, un elemento della griglia prodotti o “status”:”ok” da un health endpoint.
Troppo permissivi. Accettare qualsiasi codice 2xx o 3xx nasconde guasti reali. Accettare solo 200 da un endpoint che restituisce legittimamente 204 ne crea di falsi. Fai corrispondere il controllo a ciò che l’endpoint restituisce davvero.
La verifica del contenuto riduce allo stesso tempo i falsi allarmi e gli allarmi mancati: una pagina di errore del proxy che restituisce 200 fa fallire il controllo, mentre una modifica estetica no.
Monitora l’URL giusto
Alcuni URL sono per natura pessimi obiettivi di monitoraggio. Le pagine dietro una protezione anti-bot o un web application firewall possono bloccare di tanto in tanto il traffico di monitoraggio, e sembra downtime. Le pagine con un rate limiting aggressivo possono restituire 429 dopo una raffica di controlli. Le pagine protette da login restituiscono un redirect al modulo di accesso. E la homepage è spesso così pesantemente in cache da restare online mentre tutto ciò che c’è dietro è giù.
Un health endpoint dedicato evita tutto questo. Non è in cache, costa poco da servire, restituisce un body prevedibile e fallisce solo quando fallisce una dipendenza. Leggi come creare un health check endpoint. Se devi monitorare una pagina protetta, lascia passare il servizio di monitoraggio e invia un header user agent riconoscibile, così il traffico è facile da identificare.
Indirizza gli avvisi per singolo monitor
Un avviso è utile solo a chi può intervenire. Inviare ogni monitor a tutti trasforma gli avvisi reali in rumore per la maggior parte di chi li riceve. Indirizzali invece in base all’impatto e alla responsabilità:
Monitor (esempio)CanaleChiCheckout e callback di pagamentoNotifica push e chat di teamChi è reperibileHealth endpoint dell’API pubblicaChat di team e webhookTeam della piattaformaSito marketing e blogEmailTeam web, in orario di lavoroStaging e strumenti interniCanale chat separatoChi ne è responsabile
In Uptimecheck scegli i canali di avviso per ogni monitor. Gli avvisi arrivano via email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhook e notifiche push sul telefono, su ogni piano. Vedi avvisi e notifiche. Con i turni di reperibilità, gli avvisi push raggiungono chi è reperibile in quel momento, e l’escalation può trattenere un canale da 5 a 60 minuti e avvisare solo se nessuno ha preso in carico l’incidente. Le agency possono raggruppare i monitor per progetto cliente e scegliere i canali di ogni monitor, così gli avvisi di ogni cliente arrivano al team che lo segue.
Gestisci la manutenzione programmata
Un downtime programmato non dovrebbe mai far scattare un avviso. Prima di una migrazione o di un deploy lungo, inserisci i monitor interessati in una finestra di manutenzione. Se il tuo strumento non le prevede, mettili in pausa o sposta i loro avvisi su un canale silenzioso per la durata dei lavori, e fai della ripresa del monitoraggio una voce della tua checklist di deploy.
In Uptimecheck le finestre di manutenzione possono essere singole o ricorrenti. Durante una finestra non ci sono avvisi, né incidenti, né uptime perso, e la finestra viene mostrata sulla tua pagina di stato e può essere inviata via email agli iscritti.
Informa anche i clienti. Una nota sulla tua pagina di stato prima dei lavori, con la fascia oraria e ciò che sarà interessato, fa sì che nessuno resti sorpreso e che il supporto non riceva ticket su qualcosa che avevi pianificato. I deploy che causano ogni volta qualche secondo di errori sono un problema diverso: risolvilo con deploy progressivi o zero-downtime, non ignorando gli avvisi.
Usa le notifiche di ripristino
Una notifica di ripristino è l’avviso che dice che è tutto finito, con il downtime totale. Non riduce il numero di avvisi, ma riduce il lavoro che ciascuno comporta. Senza, qualcuno deve continuare a controllare se un breve disservizio è passato. Con questa, un’interruzione di due minuti nella notte è un avviso più un cessato allarme che può aspettare il mattino. Uptimecheck invia una notifica di ripristino dopo ogni incidente.
Rivedi i monitor più rumorosi
Una volta al mese, elenca i monitor che hanno inviato più avvisi e chiediti per ciascuno:
Ogni avviso era reale? Se no, quale impostazione l’ha causato: località, timeout, aspettativa o URL?
Qualcuno è intervenuto? Se non lo fa mai nessuno, cambia l’instradamento o rimuovi il monitor.
È il sito stesso a essere instabile? Disservizi reali brevi e frequenti non sono falsi allarmi; indicano un server sovraccarico o una dipendenza debole, e le soglie di allarme per i server possono aiutarti a trovarne la causa.
Il monitor serve ancora? Siti dismessi e vecchi server di staging sono una fonte di rumore molto comune.
I report email settimanali e mensili che riassumono uptime e incidenti rendono questa revisione rapida.
Checklist contro i falsi allarmi
Conferma ogni guasto con un secondo controllo prima di avvisare.
Imposta i timeout in base allo storico reale dei tempi di risposta.
Monitora gli URL finali, non i redirect, e verifica contenuti stabili.
Preferisci gli health endpoint alle pagine in cache o protette.
Indirizza ogni monitor alle persone che possono intervenire.
Inserisci i lavori programmati in una finestra di manutenzione e annunciali.
Rivedi ogni mese i monitor più rumorosi.
In sintesi
I falsi allarmi sono un problema di configurazione, e quasi tutti si possono risolvere in un pomeriggio. Conferma ogni guasto con un secondo controllo, verifica la cosa giusta sull’URL giusto, invia gli avvisi solo dove qualcuno può agire e continua a rivedere. Il risultato è un team che legge ogni avviso, perché ogni avviso conta.
Uptimecheck ricontrolla ogni guasto prima di avvisare e ti permette di indirizzare gli avvisi per singolo monitor. Inizia la prova gratuita di 14 giorni, senza carta di credito.