Monitoraggio sito web gratuito con avvisi in tempo reale

Perché sorvegliare la disponibilità delle tue URL?

Un uptime del 99,9 % concede 43 minuti di indisponibilità al mese. Resta da capire quando si verificano. Senza sorveglianza automatica, un'interruzione si scopre tramite l'email di un cliente, spesso diverse ore dopo l'inizio dell'incidente. Nel frattempo il funnel di conversione è rotto, i form non vengono più inviati e Googlebot registra errori 5xx.

Il meccanismo è semplice: una richiesta inviata a intervalli regolari, una risposta registrata, un avviso quando esce dai parametri attesi.

Quattro motivi per sorvegliare i tuoi endpoint:

• Rilevare prima degli utenti: un crash applicativo o un guasto del provider emerge in pochi minuti, non al primo ticket di supporto.
• Proteggere il posizionamento: errori 5xx prolungati su pagine indicizzate degradano il crawl e il ranking.
• Coprire i percorsi critici: pagina di checkout, endpoint REST, form di contatto.
• Presidiare le migrazioni: la cronologia dei check mostra quando è comparsa la regressione.

Come usare il monitoraggio HTTP in 3 passi

Passo 1: aggiungi l'URL da sorvegliare

Inserisci l'URL completa dell'endpoint, protocollo incluso:

https://captaindns.com/it/pricing

Comincia dalle URL la cui indisponibilità ha un costo immediato: home page, checkout, API pubblica.

Passo 2: regola intervallo e condizioni di avviso

Nella maggior parte dei casi bastano tre impostazioni:

• Intervallo: 5 minuti di default. Un'espressione cron copre le esigenze particolari (solo orario lavorativo, finestra di manutenzione esclusa).
• Codice HTTP atteso: qualsiasi codice 2xx di default. Indica un codice preciso se l'endpoint deve restituire esattamente quello, per esempio 301 per una redirezione o 401 per un endpoint protetto.
• Avvisi email: un interruttore per monitor. Le email partono verso l'indirizzo del tuo account CaptainDNS, non c'è alcun destinatario da inserire monitor per monitor. Sui piani a pagamento, un webhook HTTPS può instradare verso Slack, Discord o PagerDuty.

Passo 3: lancia un check e leggi le metriche

Avvia un check immediato per validare la configurazione. Il risultato appare in pochi secondi con il codice HTTP, il tempo di risposta totale e, se presente, il codice di errore. La dashboard aggrega poi l'uptime su 24 h, 7 giorni e 30 giorni, il tempo di risposta medio e il p95, la heatmap e l'elenco degli incidenti.

Come funziona un check HTTP

Ogni check si svolge in quattro fasi, e ciascuna può fallire indipendentemente dalle altre.

1. Risoluzione DNS

Il nome di dominio dell'URL viene risolto. Una risoluzione fallita (NXDOMAIN, SERVFAIL, timeout) marca il check come dns_error e attiva un avviso.

2. Apertura della connessione e handshake TLS

Si apre una connessione TCP verso l'IP risolto. In HTTPS, l'handshake TLS convalida la catena di certificati, la data di scadenza e la corrispondenza con l'hostname. Un certificato scaduto o non valido marca il check come tls_invalid.

3. Richiesta HTTP e lettura della risposta

La richiesta parte (GET di default, oppure il metodo configurato). CaptainDNS attende fino al tempo di attesa configurato, 10 secondi di default e 30 al massimo. Oltre questo limite, il check viene marcato come timeout. Codice HTTP, header e latenza totale vengono registrati.

4. Valutazione e alerting

Un check è up se il codice HTTP è un 2xx, oppure se corrisponde esattamente al codice atteso quando ne hai indicato uno; un 5xx, un codice fuori dall'atteso, un timeout o un errore di rete lo marcano down. Un passaggio confermato da up a down invia un avviso; il ritorno a up invia un'email di ripristino che chiude l'incidente.

Sorvegliare il tuo sito da più regioni

Un monitor mono-regione racconta una verità parziale. Se la tua unica sonda vive in Europa e un operatore di transito transatlantico ha un problema, il sito appare up mentre i tuoi clienti americani non lo raggiungono più. Al contrario, un incidente di rete locale vicino alla sonda fa credere a un guasto globale.

CaptainDNS esegue i check da tre regioni, sull'infrastruttura Fly.io: Europa (eu) per UE, Regno Unito e Nord Africa, Stati Uniti (us) per il Nord America e parte dell'America Latina, Asia-Pacifico (apac) per Giappone, Corea, Sud-est asiatico e Oceania. Il numero di regioni attivabili dipende dal piano: una sola (Europa) sui piani di ingresso, fino a tre sui piani superiori. Consulta piani e prezzi.

Tre strategie di rilevamento dei guasti

Avere più sonde solleva una domanda: a partire da quante regioni in errore considerare il sito come DOWN?

• Consenso (predefinita): il monitor passa DOWN se almeno metà delle regioni fallisce. I falsi positivi legati a un incidente di rete isolato vengono filtrati, un guasto vero emerge in fretta.
• Stretta: basta una sola regione DOWN. Adatta ai monitor critici (pagamento, API in tempo reale) dove anche un flap regionale breve deve emergere.
• Unanime: il monitor passa DOWN solo se tutte le regioni falliscono. Adatta alle infrastrutture distribuite (CDN attivo-attivo, edge compute) che tollerano flap regionali.

Con una sola regione attiva, le tre strategie danno lo stesso risultato: la scelta compare solo a partire da due regioni.

Analizzare la postura di sicurezza del tuo sito

Un monitor uptime risponde a una sola domanda: «il sito risponde?». Non dice nulla sulla qualità di ciò che restituisce. Un sito può rispondere 200 in 80 ms per mesi con un certificato prossimo alla scadenza, un HSTS rimosso da un deploy di reverse proxy o una CSP tornata a unsafe-inline. Il monitoraggio della postura colma questo punto cieco: ricalcola periodicamente un punteggio di sicurezza sulle URL già sorvegliate e avvisa quando si degrada.

I quattro componenti analizzati

• Certificato SSL/TLS: validità, catena di fiducia, data di scadenza, versioni di TLS accettate.
• HSTS: presenza dell'header, durata max-age, copertura dei sottodomini, stato di precaricamento.
• Header di sicurezza: CSP, X-Frame-Options, Referrer-Policy e gli altri header di difesa in profondità.
• Peso della pagina: volume delle risorse caricate, segnale di igiene delle prestazioni.

Puoi scegliere i componenti da monitorare, purché ne resti selezionato almeno uno. Deselezionare un componente lo esclude dal calcolo senza falsare il punteggio: il suo peso viene ridistribuito sui componenti restanti.

Il punteggio su 100 in due aree

Il punteggio globale è una media ponderata di Sicurezza (80 punti), che copre certificato, HSTS e header, e di Prestazioni (20 punti), che copre il peso della pagina. Ogni componente è classificato in una fascia leggibile: Eccellente, Buono, Da migliorare o Critico. La sicurezza pesa quattro volte di più, perché un certificato compromesso espone i tuoi visitatori, mentre una pagina pesante si limita a rallentare la navigazione.

Frequenza, riferimento iniziale e avvisi

Alla prima analisi, CaptainDNS fissa un riferimento iniziale senza inviare alcun avviso. In seguito, ogni cambiamento rilevante attiva un riepilogo componente per componente, e parte un avviso preventivo prima della scadenza del certificato, a soglie di 30, 14, 7, 3 e 1 giorno. Una scheda dedicata mostra il punteggio corrente e la cronologia su 180 giorni.

L'analisi della postura viene eseguita solo dall'Europa: certificato, HSTS e header non variano in base al punto di osservazione. È disponibile a partire dal piano Solo, con un intervallo minimo tra due analisi e un numero di monitor per dominio registrabile che variano in base al piano (consulta piani e prezzi).

Avvisi email e webhook

Un avviso parte appena un check esce dalle condizioni attese. Ecco il quadro riassuntivo.

Tre protezioni contro il rumore

Un sito che va in flap può generare decine di avvisi all'ora. Tre meccanismi lo impediscono:

1. Conferma su 2 fallimenti consecutivi: di default, nessun avviso parte prima di due check falliti di fila. La soglia si regola da 1 a 10 fallimenti nella configurazione del monitor.
2. Distanziamento progressivo dei promemoria: un avviso all'inizio del downtime, poi al massimo un promemoria all'ora nelle prime 24 ore dell'incidente, e un promemoria ogni 24 ore oltre. Un avviso di ripristino chiude l'incidente al ritorno.
3. Disattivazione automatica: un giorno conta come perso quando nessun check della giornata è riuscito. Al quinto giorno perso consecutivo parte un'email di avvertimento; al settimo, il monitor viene disattivato.

L'email di avviso contiene l'URL interessata, il codice HTTP o il tipo di errore, la latenza dell'ultimo check valido, il timestamp UTC e locale, e un link alla dashboard. Nessun pixel di tracking.

Webhook HTTP

L'email non è il canale adatto per instradare verso Slack, Discord, PagerDuty o un sistema interno di incident management. Sui piani a pagamento, uno o più endpoint HTTPS ricevono gli eventi in POST JSON, firmati con un secret condiviso per validare l'origine lato ricevente. Ogni webhook si iscrive alle categorie che ti interessano, tre in tutto: Monitoring, Deployment e DNS. Gli avvisi di disponibilità rientrano in Monitoring e possono partire verso un canale Slack ops, mentre un secondo webhook riceve solo gli eventi Deployment. In caso di mancata consegna, CaptainDNS riprova con un backoff esponenziale e registra ogni tentativo.

Metriche di uptime, latenza p95 e heatmap 30 giorni

La dashboard aggrega i check grezzi in sei metriche.

La latenza p95 è l'indicatore di riferimento delle prestazioni percepite. La media nasconde i picchi; il p95 dice cosa sperimentano i tuoi utenti nel 5 % dei casi peggiori.

Heatmap 30 giorni

La heatmap visualizza gli ultimi 30 giorni sotto forma di griglia colorata. Ogni cella copre un'intera giornata UTC, mai una finestra più fine, e prende il colore dall'uptime del giorno: verde sopra il 99,5 %, arancione tra il 90 % e il 99,5 %, rosso sotto il 90 %, grigio in assenza di dati.

Cronologia e conservazione dei dati

Ogni singolo check resta consultabile per 30 giorni sul piano gratuito: timestamp, codice HTTP, tempo di risposta totale, eventuale codice di errore. Passato questo termine, i check unitari vengono eliminati automaticamente. La conservazione dettagliata aumenta sui piani superiori, entro il limite di 90 giorni applicato a tutti i piani. Gli aggregati giornalieri (uptime, latenza media) non vengono mai eliminati; la profondità di cronologia leggibile su una pagina di stato pubblica dipende dal piano, da 30 giorni sul piano gratuito a diverse centinaia di giorni oltre. Eliminare un monitor cancella tutti i suoi dati.

Casi d'uso concreti

Caso 1: un deploy rompe la home page

Sintomo: un deploy del venerdì sera va in produzione. Il lunedì mattina un cliente segnala che il form di contatto restituisce un errore dal fine settimana.

Diagnosi: la cronologia dei check mostra un passaggio a down con codici 500 alle 21:12 di venerdì, poi 61 ore di downtime continuo. L'avviso email era effettivamente partito, verso un indirizzo che nessuno leggeva più.

Azione: instradare gli avvisi della categoria Monitoring verso un webhook Slack oltre che via email, e aggiungere un monitor dedicato sull'endpoint del form invece che sulla sola home page.

Caso 2: falso allarme su un incidente di rete regionale

Sintomo: un avviso DOWN arriva alle 3 del mattino. Il sito risponde normalmente dalla tua postazione.

Diagnosi: il monitor gira su tre regioni con strategia Stretta. Il dettaglio per regione mostra timeout dalla sola sonda apac, per 12 minuti, con eu e us a 200. Non è un guasto del sito ma un incidente di transito locale.

Azione: passare questo monitor su Consenso, che richiede almeno metà delle regioni in errore. Riservare Stretta agli endpoint dove un flap regionale è già un incidente per il cliente, come un'API di pagamento.

Caso 3: certificato scaduto di domenica

Sintomo: il sito risponde 200 da settimane, l'uptime è al 100 %, eppure i browser mostrano un avviso di sicurezza.

Diagnosi: il rinnovo automatico del certificato è fallito in silenzio dopo un cambio di configurazione del reverse proxy. Il monitor uptime non ha segnalato nulla prima della scadenza: rileva un certificato non valido solo una volta passata la data, mai nelle settimane che la precedono.

Azione: attivare il monitoraggio della postura su questo monitor. L'avviso di scadenza parte a soglie di 30, 14, 7, 3 e 1 giorno, e il punteggio scende appena il certificato o l'HSTS regrediscono.

Confronto degli strumenti di monitoraggio sito web

CaptainDNS non è uno strumento di monitoraggio specializzato: è una dashboard DNS, SPF, DKIM, DMARC e blacklist a cui si aggiungono il monitoraggio HTTP e la postura di sicurezza, con un'infrastruttura dati operata nell'Unione europea. La scelta si gioca quindi sul perimetro. Se sorvegli solo l'uptime e ti servono decine di monitor gratuiti, uno strumento specializzato come UptimeRobot risponde meglio al bisogno. Se cerchi pagine di stato molto personalizzabili, BetterStack è più maturo su quel terreno. CaptainDNS ha senso quando il monitoraggio HTTP estende un monitoraggio DNS ed email già attivo, e quando la localizzazione europea del trattamento conta. Quote e prezzi esatti nella pagina piani e prezzi.

Quote, limiti e piani disponibili

Il piano gratuito include 1 monitor HTTP verificato ogni 5 minuti dall'Europa, ossia 288 check al giorno, con avvisi email illimitati, 30 giorni di cronologia dettagliata, heatmap, latenza p95 e 1 pagina di stato pubblica, senza carta di credito. I piani a pagamento aumentano il numero di monitor, il numero di regioni attivabili, la durata di retention e il numero di webhook simultanei, e sbloccano il monitoraggio della postura a partire da Solo. Il dettaglio completo è aggiornato nella pagina piani e prezzi, che fa fede in caso di divergenza con questa pagina.

Sorvegliare il tuo sito dall'Europa: GDPR e sovranità

Il monitoraggio HTTP è un trattamento di dati: trasmetti URL e talvolta header di autenticazione. CaptainDNS opera la sua infrastruttura dati dall'Unione europea, con una sonda Europa in Francia e Germania, un database PostgreSQL e backup in Francia, e un team tecnico europeo. Le sonde Stati Uniti e Asia-Pacifico sono opzionali ed eseguono solo i check: i risultati vengono scritti nel database europeo, che resta l'archiviazione primaria qualunque sia il piano. La dashboard non usa cookie di tracking né script di analytics di terzi. Sei titolare del trattamento per i tuoi monitor e CaptainDNS agisce come responsabile del trattamento ai sensi dell'articolo 28 del GDPR; il DPA è disponibile su richiesta.

Limiti del monitoraggio HTTP

Il monitoraggio HTTP di CaptainDNS non copre i casi seguenti:

• Monitoraggio TCP puro su porte non HTTP (SMTP, FTP, database).
• Transazioni multi-step: percorso utente su più pagine con asserzioni successive.
• Sonde fuori dalle tre regioni Europa, Stati Uniti e Asia-Pacifico: né Sud America, né Africa, né Medio Oriente.
• Endpoint non pubblici: un'URL dietro una VPN o un firewall privato resta irraggiungibile dalle nostre sonde.

Gli avvisi Slack, Discord, PagerDuty e Opsgenie non passano da integrazioni native: si ottengono tramite i webhook HTTPS, lasciando alla destinazione la formattazione finale.

FAQ - Domande frequenti

D: Che cos'è il monitoraggio sito web?

R: Il monitoraggio sito web consiste nel verificare di continuo la disponibilità e la latenza di un'URL HTTP. Lo strumento invia una richiesta a intervalli regolari, registra la risposta e attiva un avviso in caso di errore. Il disservizio viene così individuato prima dei tuoi utenti.

D: Con quale frequenza CaptainDNS verifica la mia URL?

R: Di default, un check HTTP ogni 5 minuti su ciascuno dei tuoi monitor, ossia 288 verifiche al giorno. Un'espressione cron permette di personalizzare la cadenza: check ogni minuto in orario lavorativo, finestra di manutenzione esclusa.

D: Come ricevere un avviso quando il mio sito cade?

R: Attiva gli avvisi email alla creazione del monitor: partono verso l'indirizzo del tuo account CaptainDNS, senza destinatario da inserire. Appena un guasto viene confermato (5xx, timeout, errore DNS, certificato TLS non valido), parte un avviso. I promemoria successivi sono distanziati di almeno un'ora, e un'email di ripristino chiude l'incidente al ritorno del sito.

D: Cosa significa un uptime del 99,9 %?

R: Un uptime del 99,9 % concede circa 8 ore e 45 minuti di indisponibilità all'anno, ossia 43 minuti al mese. È la soglia comunemente adottata in produzione. Al 99,99 %, il budget scende a 52 minuti all'anno.

D: CaptainDNS è gratuito per sorvegliare il mio sito?

R: Il piano gratuito include 1 monitor HTTP verificato ogni 5 minuti, avvisi email illimitati, heatmap a 30 giorni e latenza p95, senza carta di credito. Le quote degli altri piani sono dettagliate nella pagina dei prezzi.

D: Posso monitorare un'URL autenticata o un endpoint privato?

R: Sì per le URL pubbliche. Gli header HTTP personalizzati (Authorization, X-API-Key) permettono di interrogare un endpoint protetto da token. Un'URL dietro una VPN o un firewall privato resta irraggiungibile dalle nostre sonde.

D: Come condividere i miei risultati di monitoraggio?

R: Collega il tuo monitor a una pagina di stato pubblica CaptainDNS. La pagina espone uptime, latenza e cronologia degli incidenti ai tuoi clienti, senza aprire loro la tua dashboard privata.

D: Che cos'è il punteggio di postura di sicurezza?

R: È una valutazione su 100 ricalcolata periodicamente su quattro componenti: certificato SSL/TLS, HSTS, header di sicurezza e peso della pagina. Si ripartisce tra Sicurezza (80 punti) e Prestazioni (20 punti). CaptainDNS ti avvisa a ogni regressione e prima della scadenza del certificato. Disponibile a partire dal piano Solo.

D: Quali componenti analizza la postura e con quale frequenza?

R: Certificato SSL/TLS, HSTS, header di sicurezza HTTP e peso della pagina. Scegli i componenti da monitorare (almeno uno) e la frequenza, da una volta all'ora a una volta al giorno in base al piano. Il peso della pagina resta misurato al massimo una volta al giorno.

Strumenti complementari

Risorse utili

• Google SRE Book: Service Level Objectives (definizione di riferimento di SLA, SLO e budget di errore alla base del 99,9 %)
• RFC 6797 (specifica di HTTP Strict Transport Security, uno dei componenti del punteggio di postura)
• MDN: Content-Security-Policy (documentazione dell'header CSP e delle sue direttive)
• Documentazione Let's Encrypt (rinnovo automatico e durata di vita dei certificati TLS)
• CA/Browser Forum (organismo che fissa i requisiti di base dei certificati pubblici, inclusa la durata massima di validità)
• Fly.io: regioni (elenco delle regioni dell'infrastruttura su cui girano le sonde)