Il monitoraggio uptime di un sito web invia una richiesta al tuo sito a intervalli fissi e verifica la risposta. Se la risposta è sbagliata, lenta o assente, ricevi un avviso. Sembra semplice, e lo è. Il valore sta nei dettagli: quanto spesso controlli, cosa conta come errore, come viene confermato un errore e quanto in fretta lo viene a sapere la persona giusta.
Uptimecheck esegue controlli HTTP(S), ping e porta ogni 1, 2, 5, 10, 15 o 30 minuti oppure ogni ora. Ogni controllo registra il codice di stato e il tempo di risposta, così vedi sia i disservizi sia i periodi di lentezza. Se prima vuoi le basi, leggi cos’è il monitoraggio uptime e perché è importante.
Tipi di controllo
HTTP(S): richiedi un URL con GET, POST o un altro metodo, invia header e body personalizzati e verifica il codice di stato, una parola chiave o i campi JSON nella risposta.Ping: verifica che un host risponda in rete, con il tempo di andata e ritorno.Porta: verifica che un servizio, come un server di posta o un database in ascolto, accetti connessioni.
Per i percorsi che attraversano più pagine, come il login o il checkout, usa il monitoraggio dei flussi.
Perché controllare ogni minuto, e controllare due volte
Il downtime costa denaro minuto per minuto. Se il tuo checkout risponde 503 alle 03:12 e nessuno se ne accorge fino al primo ticket di supporto, hai perso ore invece di minuti. La nostra guida al costo del downtime di un sito analizza i numeri.
Uptimecheck esegue i controlli da Stoccolma, Londra e New York e conferma ogni errore da una seconda località prima di aprire un incidente. Così si riducono i falsi allarmi dovuti a una singola richiesta persa o a un breve intoppo di rete, mentre un disservizio reale ti raggiunge comunque entro un minuto o due. La nostra guida per ridurre i falsi allarmi spiega perché è importante.
Dal controllo fallito alla soluzione
03:12: il controllo su northwind.shop/checkout restituisce 503.03:12: fallisce anche il secondo controllo. Si apre un incidente con la risposta in errore e uno screenshot di ciò che vedevano i visitatori.03:13: lo sviluppatore reperibile riceve una notifica push sul telefono e il canale del team riceve i dettagli su Slack.03:19: i controlli tornano a passare. Parte una notifica di ripristino con il downtime totale.
Gli avvisi arrivano via email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhook e notifiche push sul telefono, con ogni piano. Consulta avvisi e notifiche per l’instradamento e l’escalation, la gestione degli incidenti per ciò che succede dopo l’avviso, e abbina il monitoraggio a una pagina di stato così i clienti sanno cosa sta succedendo senza aprire un ticket.
Tempi di risposta suddivisi per fasi
Ogni controllo HTTP salva il suo tempo di risposta, suddiviso in DNS, connessione, TLS, server e download. Una fase server lenta indica la tua applicazione; DNS o TLS lenti indicano l’infrastruttura. I grafici mostrano la mediana, il 95° percentile e la media, così una coda lenta non si nasconde dietro una buona media. Scopri di più sul tempo di risposta di un sito.
Imposta un limite, ad esempio 2.000 ms, e ricevi un avviso di lentezza quando tre controlli di fila superano quel valore, e un altro quando il sito torna veloce. Il tempo di lentezza non conta come downtime.
La pagina del monitor elenca i controlli più recenti. Tre o più controlli uguali di fila si raggruppano in una riga, ad esempio “OK · 200 × 18” con l’intervallo dei tempi di risposta, e si espandono per mostrare ogni controllo. Un errore non viene mai raggruppato in una serie di controlli riusciti, e il secondo controllo che conferma un errore mantiene la propria riga. Se un monitor non in pausa non viene controllato per il doppio del suo intervallo, la pagina indica “Nessun dato recente” con l’orario dell’ultimo controllo, così uno stato vecchio non passa mai per attuale.
Verifica che la pagina funzioni davvero
Una pagina può rispondere 200 ed essere comunque rotta: un elenco prodotti vuoto, un messaggio di errore, una pagina di manutenzione. Aggiungi controlli sulla risposta che devono passare tutti:
Stato atteso: codici o intervalli, come 200-299 o 200,301.Parola chiave: testo che la pagina deve o non deve contenere, come “Aggiungi al carrello”.JSON e header: per le API, un campo come $.status uguale a ok, oppure un header che deve essere presente.
I monitor HTTPS leggono anche il certificato e ti avvisano prima che scada. Vedi monitoraggio SSL.
Configura il tuo primo monitor
Aggiungi l’URL, scegli il tipo di controllo, definisci cosa conta come risposta valida e scegli i canali da avvisare. “Richiesta di prova” mostra la risposta prima di salvare, e il primo controllo parte subito. La maggior parte dei team inizia con tre monitor: la homepage, la pagina di conversione più importante (checkout, registrazione o login) e l’endpoint API principale. Arrivi da UptimeRobot, Better Stack, Pingdom o StatusCake? Importa i tuoi monitor con le relative impostazioni e controllali uno per uno prima che venga creato qualcosa.
Cosa conta come non disponibile
Un controllo fallisce quando la richiesta va in timeout, la connessione viene rifiutata, il certificato non è valido, il codice di stato non è quello atteso o un controllo sulla risposta non è soddisfatto. L’uptime è la quota di tempo senza un disservizio confermato, e le finestre di manutenzione non vengono conteggiate. I report mostrano l’uptime per monitor in qualsiasi periodo rispetto al tuo obiettivo SLA, con esportazione CSV.
I piani partono da 9 € al mese con fatturazione annuale o 12 € con fatturazione mensile, IVA esclusa, con controlli ogni minuto su ogni piano a pagamento, oppure gratis per 5 monitor controllati ogni 5 minuti. Confronta monitor, pagine di stato e storico (1, 2 o 3 anni) nella pagina dei prezzi, esplora la demo dal vivo senza registrarti oppure inizia una prova gratuita di 14 giorni senza carta.