La settimana scorsa una Fortune 500 ha perso un valore stimato di 14 milioni di dollari in circa sei ore perché un singolo certificato SSL è scaduto in silenzio e nessuno se n'è accorto finché i clienti non hanno iniziato a lamentarsi su Twitter. L'email di rinnovo era stata inviata. È finita in una inbox condivisa che il precedente DevOps lead aveva in carico. Lui se n'era andato a marzo. Il certificato è scaduto un sabato alle 02:14 UTC. L'on-call della platform team non è stato chiamato perché tecnicamente nulla era "down" — il sito stava servendo traffico, solo con un enorme avviso rosso del browser che terrorizzava ogni cliente pagante.

Non è una storia rara. È il singolo outage prevenibile più comune che vediamo, e non ha nulla a che vedere con architettura cloud o orchestrazione di container. Succede perché la maggior parte dei team tratta monitoraggio del dominio, monitoraggio SSL e monitoraggio uptime come tre problemi separati gestiti da tre tool separati — o, più spesso, da nessuno. Questa guida ti accompagna nello stack completo a 3 livelli, cosa monitorare a ogni livello e come collegarlo per non farti più trovare scoperto.

Lo stack di monitoraggio a 3 livelli#

Ogni proprietà web pubblica ha tre modalità di guasto indipendenti che producono tutte sintomi da "il sito è down" ma richiedono rimediazioni completamente diverse:

Scadenza del dominio — la registrazione decade, il registrar si riprende il dominio e il tuo DNS smette di risolvere. Tempo di recupero: ore o giorni. Costo: catastrofico.
Scadenza del certificato SSL — il DNS risolve ancora, il server è ancora in piedi, ma il certificato è oltre la sua data notAfter. I browser bloccano la connessione. Tempo di recupero: minuti se automatizzato, ore se manuale.
Uptime / fallimento HTTP — il DNS risolve, il certificato è valido, ma il server restituisce un 5xx, va in timeout o è stato rediretto a una parking page dal tuo hosting provider. Tempo di recupero: dipende interamente dalla causa radice.

La ragione per cui servono tutti e tre i livelli è che ognuno intercetta un guasto che gli altri si perdono. Il monitoraggio uptime ti dirà che il sito è rotto — ma solo dopo che il certificato SSL è già scaduto e i clienti sono già scappati. Il monitoraggio del dominio intercetta il decadimento della registrazione settimane prima che il dominio cada davvero. Il monitoraggio SSL intercetta il problema del certificato 30 giorni prima che compaia l'avviso del browser. Sovrapponi tutti e tre e ottieni una difesa stratificata; salta uno solo e hai un buco grande abbastanza da farci passare un camion.

Livello 1: monitoraggio della scadenza del dominio#

La scadenza del dominio è l'outage più prevenibile di internet, e anche il più imbarazzante. Microsoft l'ha fatto. Google l'ha fatto (due volte). Foursquare l'ha fatto. Sorenson Media l'ha fatto. Ognuno di questi è stato un outage di molte ore causato dalla scadenza di una carta di credito o da un'email di rinnovo finita nella inbox sbagliata.

Perché le email del registrar non bastano#

I registrar inviano i promemoria di rinnovo. Vanno a qualunque indirizzo email fosse in archivio quando il dominio è stato registrato per la prima volta, che spesso è il Gmail personale di un consulente che se n'è andato tre anni fa. Anche quando l'indirizzo è giusto, le email del registrar finiscono regolarmente nello spam, e anche quando non ci finiscono, sembrano identiche alle email di phishing che si fingono avvisi di rinnovo, quindi la gente le cancella.

L'auto-rinnovo dovrebbe risolvere tutto questo, ma fallisce in silenzio in tre modi comuni:

La carta di credito in archivio scade.
La carta viene rifiutata per frode (i rinnovi annuali sembrano insoliti alle banche emittenti).
Il toggle dell'auto-rinnovo del registrar viene spostato durante una migrazione di account o un redesign del control panel.

Il monitoraggio esterno è l'unico backstop affidabile.

Come monitorare la scadenza del dominio#

Il protocollo è RDAP (il sostituto moderno di WHOIS) con fallback su WHOIS per i TLD che ancora non supportano RDAP. Un controllo giornaliero basta — le date di scadenza dei domini non si muovono di minuto in minuto, e i registrar applicano i propri grace period sopra a qualunque cosa tu pubblichi.

# Quick manual check via command line
curl -s "https://rdap.org/domain/example.com" | jq '.events[] | select(.eventAction=="expiration")'

Pipa quello in un cron job e hai un monitor di base. Ma ti servono anche soglie di alert, logica di retry per i fallimenti WHOIS transitori e un modo per distinguere tra "scaduto" e "rinnovato ma la data non si è ancora propagata". Per questo un tool hosted è di solito più rapido che costruirlo.

La cadenza di alert a 30/14/7/2 giorni#

Manda alert in quattro momenti: 30 giorni prima (pianificazione), 14 giorni prima (azione), 7 giorni prima (escalation) e 2 giorni prima (panico). Più frequente di così crea fatigue. Meno frequente di così non lascia margine se il primo alert viene perso.

Cosa significa davvero "scaduto"#

I domini non cadono nel secondo in cui scadono. La maggior parte dei TLD ha una timeline a più stadi:

Giorno 0–30 dopo la scadenza: grace period. Il dominio è sospeso (no DNS) ma il registrante può rinnovare al prezzo normale.
Giorno 30–60: redemption period. Il rinnovo è ancora possibile ma con una redemption fee da $80–$200.
Giorno 60–90: pending delete. Il dominio è bloccato e non può essere rinnovato.
Giorno 90+: dropped. Chiunque può registrarlo.

Se un dominio che possiedi entra in redemption, probabilmente lo paghi ma puoi ancora recuperarlo. Una volta in pending delete stai gareggiando con drop-catcher professionisti. Non lasciarlo arrivare lì.

Nova Uptime ha un domain expiry checker gratuito per i lookup occasionali, e la dashboard esegue RDAP quotidianamente su ogni dominio monitorato con la cadenza di alert 30/14/7/2 giorni integrata.

Livello 2: monitoraggio del certificato SSL#

La scadenza del certificato SSL è, di gran lunga, la singola causa più comune di outage da "il sito è down". Microsoft Teams è andato al buio a febbraio 2020 per via di un certificato di auth scaduto. Microsoft Azure ha avuto un outage di molte ore nel 2021 per la stessa causa. Spotify l'ha fatto. LinkedIn l'ha fatto. Google Voice l'ha fatto. Il filo conduttore: la cadenza di rotazione di 90 giorni di Let's Encrypt ha addestrato l'intera industria ad aspettarsi automazione, e quando l'automazione si rompe, si rompe in silenzio.

Cosa monitorare davvero su un certificato#

Un certificato ha più modalità di guasto del solo notAfter. Un monitor completo verifica:

notBefore e notAfter — la finestra di validità. Alert a 30, 14, 7 e 2 giorni prima di notAfter.
Completezza della catena di issuer — il tuo server deve servire la catena intermedia completa. Un bug di deploy comune è inviare solo il certificato leaf; funziona in Chrome (che cacha gli intermedi) ma si rompe in Firefox, nei browser mobile e nella maggior parte dei client API.
Match Subject e SAN — i Subject Alternative Names del certificato devono includere l'hostname richiesto. I cert wildcard vanno bene ma assicurati che la wildcard copra effettivamente il sottodominio che stai colpendo.
Cipher suite e versione TLS — TLS 1.0 e 1.1 sono deprecati. TLS 1.2 è il pavimento; TLS 1.3 è preferito. Cipher deboli (RC4, 3DES) devono far fallire il tuo check.
Presenza dell'OCSP staple — se hai configurato l'OCSP stapling e smette di funzionare, vedrai avvisi del browser anche con un cert valido.

Modalità di guasto SSL comuni#

In ordine approssimativo di frequenza, i guasti che vediamo in produzione:

Certificato scaduto. L'hook di auto-rinnovo non è scattato. Il cron job è morto. Il rinnovo è andato a buon fine ma il nuovo cert non è stato ricaricato dal web server.
Certificato intermedio mancante o sbagliato. Certbot genera la catena ma uno script di deploy la sovrascrive, oppure un reverse proxy è configurato con ssl_certificate invece di ssl_certificate fullchain.pem.
Hostname mismatch. Il cert è stato emesso per example.com ma l'utente sta colpendo www.example.com e il SAN non include www.
Cert servito sbagliato (bug SNI). Il server ospita più siti e viene servito il cert del vhost di default invece di quello per-sito.
Drift dell'orologio. L'orologio del server è sfasato di più di qualche minuto, facendo apparire i cert validi come scaduti o non-ancora-validi.

Frequenza di check raccomandata#

Quotidiana è il minimo. Per endpoint critici per i ricavi — API di pagamento, flussi di login, widget embeddabili — orario è ragionevole. Il check è economico (un singolo TLS handshake per endpoint) quindi la frequenza raramente è il collo di bottiglia.

Disastri reali sui cert#

Lo schema si ripete ogni anno:

Microsoft Teams, feb 2020 — certificato interno scaduto ha tirato giù Teams per ore durante il picco di una giornata lavorativa.
Microsoft Azure, marzo 2021 — la scadenza del cert TLS ha causato un outage di 14 ore che ha colpito l'autenticazione su più property Microsoft.
Spotify, in più anni — i certificati scaduti hanno causato almeno tre outage visibili pubblicamente.
GitHub status page — a un certo punto la status page stessa serviva un cert scaduto, il tipo di ironia che fa ridere nervosamente gli ingegneri.

Nessuna di queste aziende mancava del talento ingegneristico per prevenire la scadenza. Mancava del monitoraggio stratificato che l'avrebbe intercettata. L'SSL expiry checker gratuito di Nova Uptime fa un check one-shot; la dashboard esegue lo stesso check su uno schedule e manda alert a 30/14/7/2 giorni.

Livello 3: monitoraggio uptime / HTTP#

Il monitoraggio uptime è il livello che intercetta tutto ciò che i primi due livelli non possono anticipare: crash del server, deploy andati male, memoria fuori controllo, esaurimento del pool di connessioni del database, DDoS, problemi del provider di hosting, misconfigurazione DNS, cache poisoning del CDN e le altre cinquanta modalità di guasto che non si presentano in un cert o in un record del registrar.

Cosa controllare#

Un monitor HTTP utile controlla più del semplice "la richiesta ha restituito 200?" Nello specifico:

Status code — qualsiasi cosa nel range 2xx è sano, 3xx potrebbe essere un redirect a una parking page (sospetto), 4xx e 5xx sono fallimenti.
Response time — la latenza p95 che cresce è l'indicatore principale di un problema di database o CPU.
Contenuto del body di risposta — idealmente controlla una stringa nota-buona (un endpoint heartbeat che restituisce {"status":"ok"}) così intercetti il caso in cui il server restituisce 200 ma l'applicazione è crashata e sta servendo una pagina d'errore.
Successo del TLS handshake — incorpora parte del livello 2 nello stesso check.
Tempo di risoluzione DNS — un lookup DNS lento è spesso il primo segno di un problema con CDN o upstream.

Perché conta il multi-region#

Un monitor a singola regione è una macchina di falsa fiducia. Il tuo monitor vive in us-east-1. Anche la tua applicazione. AWS ha un problema regionale. Cadono entrambi. Il tuo monitor riporta "site up" perché il monitor è morto. Il monitoraggio multi-region (o, come minimo, cross-region — monitora in us-west se la tua app è in us-east) elimina questa classe di falso negativo.

Cattura screenshot dei guasti#

Quando un check fallisce, fai uno screenshot della pagina renderizzata. Vale tanto oro quanto pesa durante i postmortem perché cattura esattamente quello che l'utente ha visto al momento del guasto — non quello che dicono i log, non quello che il monitor sintetico pensa sia successo, ma quello che era sullo schermo. Era un 502? Una pagina di manutenzione? Uno schermo bianco vuoto? Un challenge Cloudflare? Lo saprai in due secondi invece che in due ore.

Alert multi-canale#

L'email è necessaria ma non sufficiente. Le email vengono bufferizzate, raggruppate e ignorate. Gli alert critici devono bypassare l'email e raggiungere un umano direttamente. Nova Uptime supporta email, WhatsApp (Baileys, senza addebiti per messaggio) e webhook in uscita (firmati HMAC) per integrarsi con PagerDuty, Opsgenie, Slack o qualsiasi sia il tuo tooling di incident.

Setup dello stack completo con Nova Uptime#

Ecco il setup pratico, end to end, più o meno nell'ordine in cui lo faresti.

1. Aggiungi il dominio#

Incolla l'URL nella dashboard. Nova Uptime esegue un check HTTP immediato, un TLS handshake, un lookup RDAP/WHOIS per la scadenza del dominio e un fetch del favicon. Vedi tutti e quattro i risultati entro 60 secondi.

2. Configura l'intervallo di check#

Piano Free: intervallo a 15 minuti. Piano Pro: fino a 59 secondi. Piano Agency: stesso pavimento di 59 secondi con limiti di dominio più alti. Per la maggior parte dei siti marketing, 5 minuti vanno bene. Per le API di pagamento, i check a 59 secondi sono corretti.

3. Connetti WhatsApp#

In Settings → WhatsApp, scansiona il QR code una volta. Da lì in poi, ogni alert può essere inviato al tuo numero WhatsApp senza costo per messaggio (piano Free = 1 numero, Pro = 3, Agency = 5). La consegna WhatsApp è più veloce e più difficile da ignorare dell'email.

4. Aggiungi email in CC per il team#

Sulla pagina di settings di ogni dominio, aggiungi fino a 5 email in CC. È la lista di distribuzione del team per quel dominio specifico — la homepage potrebbe avvisare il marketing lead, l'API potrebbe avvisare l'on-call engineer.

5. Testa gli alert con un guasto deliberato#

La singola cosa migliore che puoi fare dopo aver collegato il monitoraggio è romperlo deliberatamente una volta. Punta una URL monitorata a un hostname che non esiste, o revoca temporaneamente il cert, e guarda l'alert partire. Se non parte, hai appena scoperto un bug di config nel momento più economico possibile.

6. Sappi quando fare upgrade#

La fascia gratuita copre 5 domini ed è abbastanza per progetti personali e team piccoli. Le due ragioni per fare upgrade sono: (a) hai superato i 5 domini, o (b) ti servono intervalli di check sotto i 15 minuti. Dettagli dei prezzi sulla pricing page.

Strategia di alert: evitare la fatigue#

Il modo più rapido di rovinare uno stack di monitoraggio è alertare troppo. Dopo tre falsi positivi in una settimana, ogni ingegnere del team inizia a ignorare il canale, e ora hai un monitoraggio dal valore negativo.

Tre regole pratiche:

Differenzia per severità. Gli avvisi di scadenza dominio a 30 giorni sono informativi — vanno solo via email. Gli avvisi SSL a 7 giorni sono warning — email più un canale Slack. Sito down per 2+ minuti è critico — WhatsApp, telefono che vibra, paging dell'on-call. Non mandare tutto a tutti i canali.

Metti in pausa durante la manutenzione pianificata. Se stai facendo deploy, applicando una migration di database o ruotando un cert, metti in pausa il monitor pertinente per la finestra di manutenzione. Nova Uptime ha la pausa per dominio e un toggle globale "metti in pausa tutte le notifiche" in Settings. (Il monitoraggio continua — solo le notifiche sono in pausa, così puoi rivedere i log dopo.)

Limita il rate degli alert "ancora down". Una volta che un dominio è stato segnalato come down, non ti serve una notifica al minuto. Nova Uptime invia l'alert iniziale, poi promemoria orari di "ancora down" (su email e WhatsApp) finché il dominio non recupera. L'alert di recovery scatta sempre subito.

Instrada per canale. L'email va bene per digest, report settimanali e alert informativi. WhatsApp va bene per gli alert critici che richiedono un umano nei prossimi 5 minuti. I webhook vanno bene per l'automazione (creare incidenti PagerDuty automaticamente, postare su Slack, attivare runbook).

Qualche caso degno di nota:

LinkedIn, ottobre 2022 — scadenza SSL di molte ore su un sottodominio che ha colpito la consegna dei messaggi. Il sito principale è rimasto su; il problema è stato mascherato finché i clienti non l'hanno segnalato.
Cloudflare, 2021 — una misconfigurazione della catena di certificati intermedi ha causato problemi diffusi per i siti che usavano il servizio cert edge di Cloudflare. Il cert leaf era valido; la catena era incompleta.
GitHub Status, vari incidenti — la status page stessa, in vari momenti, ha servito cert scaduti o ha avuto problemi di registrazione del dominio. La lezione è che il meta-monitoraggio (la cosa che ti dice quando il monitoraggio è rotto) è esso stesso qualcosa che va monitorato.

Checklist di setup#

Esegui questa lista e hai una difesa stratificata:

Conclusione#

Monitoraggio dominio, alert SSL e monitoraggio uptime non sono tre tool che si bullonano insieme. Sono tre livelli di una sola strategia di defence-in-depth, e qualsiasi stack di monitoraggio che gestisce solo uno o due di questi prima o poi ti tradirà nel momento peggiore possibile. Nova Uptime ti dà tutti e tre in un'unica dashboard con alert email e WhatsApp sul piano gratuito. Iscriviti gratis e monitora fino a cinque domini in meno di cinque minuti.

Letture correlate#

Uptime Monitoring for SaaS Applications — playbook di monitoraggio multi-tenant per i team SaaS
DMARC Policy Setup Guide — il complemento lato email del monitoraggio dominio
Free SSL Expiry Checker — analisi single-shot del certificato
Free Domain Expiry Checker — lookup RDAP/WHOIS con stato grace-period
Free Email Health Checker — assicurati che le tue email di alert arrivino davvero

Monitoraggio dominio con alert SSL: la guida completa al setup 2026