Un incidente si apre solo dopo due controlli falliti di fila: il controllo fallito viene ripetuto da un’altra località, oppure dallo stesso punto 10 secondi dopo quando è online una sola località. Quindi, se il sito per te funziona ancora, il nostro controllo e il tuo browser stanno vedendo cose diverse. L’incidente mostra cosa ha visto il controllo.
Parti dalle prove
Apri l’incidente da Incidents. What we saw elenca ogni controllo fallito con il relativo errore. Per i siti web mostra anche:
Connected to e Resolved to: l’indirizzo IP che abbiamo raggiunto e cosa ha risposto il DNS.Redirected to, il Certificate e gli Headers come Server, CF-Ray e Retry-After.Start of the response: i primi 2 kB inviati dal server. Qui compaiono una pagina di blocco o un messaggio di errore.Uno screenshot se il server ha risposto, oppure il percorso di rete (un traceroute) se non ha risposto.
Lo screenshot viene acquisito da un browser reale su un’altra rete. Se appare a posto mentre il controllo è fallito, qualcosa tratta i nostri controlli in modo diverso, spesso una regola del firewall.
Cause comuni
Un firewall o una protezione anti-bot risponde con HTTP 403, HTTP 429 o una pagina di verifica come “Just a moment…” di Cloudflare. Il tuo browser la supera; un controllo non può risolvere una verifica. Consenti a Uptimecheck di passare il firewall.La parola chiave non è nella pagina. Le parole chiave distinguono maiuscole e minuscole e vengono cercate nell’HTML inviato dal server, quindi il testo aggiunto in seguito da JavaScript non c’è. Scegli una parola dal sorgente della pagina oppure usa un flusso in un browser reale.Redirect: il controllo ne segue fino a 10 e valuta l’ultima pagina, quindi un redirect a una pagina di login, a un cookie wall o al sito di un altro paese può far fallire una parola chiave. Oltre 10 si ottiene Too many redirects.Il codice di stato: di default, da 200 a 399 conta come up. Una pagina dietro login che deve rispondere 401 richiede quel codice in Expected status codes.Il certificato: un certificato scaduto, autofirmato o emesso per un altro nome host segna il monitor come down quando Verify TLS certificate è attivo. Un certificato intermedio mancante no: i browser lo scaricano, e lo fa anche il nostro controllo, ma il monitor mostra Incomplete chain, perché alcune app e i dispositivi più vecchi non ci riescono.DNS: dopo un trasferimento, i resolver conservano la vecchia risposta finché non scade il suo TTL, quindi potremmo raggiungere il vecchio server mentre tu raggiungi quello nuovo, o viceversa. Confronta Connected to con l’indirizzo del tuo server. Un nome che si risolve solo all’interno della tua rete non può essere controllato dall’esterno, e uno che si risolve in un indirizzo privato viene rifiutato.Timeout: di default un controllo attende 10 secondi (Timeout (s)). Il tuo browser potrebbe mostrare una copia in cache, o una da un CDN vicino a te, mentre il server stesso è lento.Località: i controlli partono da Stoccolma, Londra e New York. Un sito che blocca i visitatori di altri paesi, o un guasto di rete tra una di queste località e il tuo host, fallisce per noi e non per te. Il percorso di rete mostra dove si fermano i pacchetti.Il tuo accesso: un indirizzo IP dell’ufficio autorizzato, una VPN, una sessione con login attivo o una voce nel file hosts possono far funzionare il sito solo per te.
Quando il problema è nostro
Se la rete di una delle nostre località ha problemi, la maggior parte dei siti noti che controlliamo da lì fallisce nello stesso momento. Lo teniamo d’occhio e tratteniamo gli incidenti da quella località, così non ricevi avvisi per un problema nostro.
Verifica tu stesso
Modifica il monitor e usa Test request per inviare una richiesta dai nostri server e vedere la risposta. Una volta risolta la causa, due controlli superati di fila chiudono l’incidente. Vedi come funzionano incidenti e prove e come ridurre i falsi allarmi.