Nel monitoraggio uptime la risposta breve è questa: le risposte 2xx significano che il sito è up, le 5xx che è down, e tutto ciò che sta in mezzo dipende da cosa ti aspetti da quell’URL. Un 301 va bene se la pagina è stata spostata di proposito, un 401 va bene su un endpoint API che richiede una chiave, mentre un 404 sulla pagina di checkout è un’interruzione del servizio. Il monitor giusto controlla il codice di stato che ti aspetti, non semplicemente “qualsiasi cosa tranne un errore”.
Questa guida rapida passa in rassegna le famiglie di codici di stato dal punto di vista del monitoraggio: cosa significa ogni codice, se va considerato down e come configurare i controlli perché avvisino solo in caso di problemi reali.
Le cinque famiglie in sintesi
IntervalloSignificatoPer un monitor1xxInformativo, la richiesta prosegueSi vede di rado; non è una risposta finale2xxSuccessoDi solito up3xxRedirect, la risorsa è altroveUp o down a seconda dell’intenzione4xxErrore del client, la richiesta era sbagliataDipende dall’endpoint5xxErrore del server, il server ha fallitoDown
La prima cifra ti dice di chi è la responsabilità. Un 4xx significa che per il server la richiesta era sbagliata. Un 5xx significa che il server ammette di aver fallito. Per un monitor che invia la stessa richiesta ogni minuto, però, un 4xx improvviso di solito indica che qualcosa è cambiato lato server: una pagina rimossa, un permesso modificato o un firewall che ha iniziato a bloccare.
1xx: informativi
Codici come 100 Continue, 101 Switching Protocols e 103 Early Hints sono risposte intermedie. Il client li riceve prima della risposta finale, oppure non li vede affatto. Un controllo di monitoraggio attende il codice di stato finale, quindi puoi ignorare questa famiglia. Se un controllo dovesse mai terminare con un 1xx, la connessione si è interrotta a metà risposta, e questo è un errore.
2xx: successo
CodiceNomeNote per il monitoraggio200OKLa risposta di successo standard201CreatedAtteso dopo una POST che crea qualcosa202AcceptedRichiesta in coda; l’elaborazione avviene dopo204No ContentSuccesso con corpo vuoto; comune per DELETE e per alcuni health check
Un 200 non garantisce che la pagina funzioni. Molte applicazioni intercettano i propri errori e mostrano una pagina di errore con stato 200: “Database connection failed”, un template vuoto, un avviso di manutenzione. Aggiungi la verifica del contenuto ai controlli importanti: richiedi una parola o un campo JSON che compare solo quando la pagina funziona davvero. Con un 204 non c’è un corpo da verificare, quindi controlla solo il codice di stato.
3xx: redirect
CodiceNomeUso tipico301Moved PermanentlyDa vecchio URL a nuovo URL, da HTTP a HTTPS302FoundRedirect temporaneo, spesso verso una pagina di login303See OtherRedirect dopo l’invio di un modulo con POST304Not ModifiedLa copia in cache è ancora valida; solo dopo richieste condizionali307Temporary RedirectCome il 302, ma mantiene metodo e corpo308Permanent RedirectCome il 301, ma mantiene metodo e corpo
Redirect e monitor
Gli strumenti di monitoraggio gestiscono i redirect in due modi: li seguono e riportano lo stato della pagina finale, oppure si fermano alla prima risposta e riportano il 3xx. Sappi quale dei due usa il tuo strumento per ogni controllo, perché entrambi possono nascondere dei problemi:
Se il monitor segue i redirect, una pagina che all’improvviso reindirizza alla homepage o a una schermata di login può comunque finire con un 200. La verifica del contenuto se ne accorge: la homepage non contiene le parole della tua pagina di checkout.
Se il monitor non segue i redirect, imposta come stato atteso il codice del redirect e controlla l’URL finale con un monitor dedicato.
Lo schema più sicuro è monitorare direttamente l’URL finale. Se northwind.shop reindirizza a www.northwind.shop, monitora la versione con www e aggiungi un controllo separato per il redirect solo se ti interessa, per esempio per i link di vecchie campagne. Un loop di redirect, in cui due URL puntano l’uno all’altro, si presenta come un timeout o un errore “too many redirects” e va sempre considerato down.
4xx: errori del client
CodiceNomeDown?400Bad RequestDi solito un controllo rotto o un’API cambiata401UnauthorizedAtteso sugli endpoint protetti senza credenziali403ForbiddenAtteso per i percorsi bloccati; un problema se compare all’improvviso404Not FoundDown per qualsiasi URL che dovrebbe esistere405Method Not AllowedIl controllo usa il metodo sbagliato, oppure la route è cambiata408Request TimeoutIl server ha smesso di aspettare la richiesta410GoneRimosso di proposito429Too Many RequestsRate limit raggiunto
401 e 403 sugli endpoint protetti
Alcuni endpoint devono rifiutare le richieste anonime. Un’API di amministrazione che restituisce 401 senza token funziona correttamente. Puoi monitorarla in due modi:
Aspettati il rifiuto. Imposta 401 come stato atteso. Il controllo conferma che il server è attivo e che il livello di autenticazione è al suo posto. Se dovesse mai restituire 200 senza credenziali, è un problema di sicurezza che merita un avviso.
Invia le credenziali. Aggiungi al controllo un header con la chiave API o la basic auth e richiedi un 200 con il contenuto corretto. Così testi l’intero percorso, compreso il database dietro l’endpoint.
La seconda opzione verifica di più, quindi usala per tutto ciò su cui contano i clienti. Per il monitoraggio usa una chiave dedicata di sola lettura, mai una chiave personale o di amministrazione.
Un 403 improvviso su una pagina pubblica è un’altra storia. Di solito significa che un firewall, un plugin di sicurezza o una regola della CDN ha iniziato a bloccare le richieste, a volte solo da certi paesi o intervalli IP. Se una località di monitoraggio riceve 403 e un’altra 200, la causa probabile è una regola geografica o sugli IP.
429 Too Many Requests
Un 429 significa che il server sta applicando un rate limit al client. Per il monitoraggio significa una di due cose: i tuoi limiti sono troppo severi per il traffico normale, oppure il monitor stesso raggiunge un limite perché condivide un indirizzo con altri client. Controlla l’header Retry-After e la configurazione del rate limit. Se gli utenti reali ricevono dei 429 con un carico normale, trattalo come un’interruzione del servizio.
5xx: errori del server
CodiceNomeCosa significa di solito500Internal Server ErrorL’applicazione si è bloccata su questa richiesta501Not ImplementedIl server non supporta il metodo502Bad GatewayIl proxy ha ricevuto una risposta non valida dall’applicazione dietro di lui503Service UnavailableSovraccarico, in manutenzione o senza un backend funzionante504Gateway TimeoutIl proxy ha aspettato troppo a lungo l’applicazione
Considera down ogni 5xx. I codici cambiano per dove guardare per primo: un 500 rimanda ai log dell’applicazione, un 502 a un processo applicativo bloccato o in riavvio, un 504 a query lente o chiamate esterne, e un 503 a capacità o manutenzione. La nostra guida all’errore 503 Service Unavailable approfondisce cause e soluzioni.
Alcune CDN e alcuni proxy usano codici propri nell’intervallo 5xx, come quelli da 520 a 530, per i problemi tra la CDN e il tuo server di origine. Non fanno parte dello standard HTTP, ma per un visitatore significano la stessa cosa: il sito è down.
Non tutti gli errori hanno un codice di stato
Alcune delle interruzioni più comuni non producono alcun codice di stato:
Errore DNS: il dominio non si risolve, per esempio dopo una registrazione scaduta o un record rimosso.
Connessione rifiutata o resettata: nessun servizio è in ascolto sulla porta, oppure un firewall interrompe la connessione.
Errori TLS: un certificato scaduto o non corrispondente blocca la richiesta prima ancora che inizi qualsiasi scambio HTTP.
Timeout: il server accetta la connessione ma non risponde mai in tempo.
Un buon monitor li segnala come errori indicando l’errore effettivo, così l’avviso dice “certificato scaduto” invece di un semplice “down”. Per questo conviene anche affiancare ai monitor HTTP i controlli sulla scadenza di certificati e domini.
Come impostare lo stato atteso in un monitor
Per ogni URL che monitori, decidi che aspetto ha una risposta sana e trascrivilo nella configurazione del controllo:
Scegli l’URL che conta. L’URL finale dopo i redirect, non il link abbreviato.
Imposta il metodo. GET per le pagine e, per le API, quello richiesto dall’endpoint.
Imposta lo stato atteso. Di solito 200. Usa 201, 204, 301 o 401 quando è quella la risposta prevista.
Aggiungi le credenziali, se servono. Header o basic auth per gli endpoint protetti.
Aggiungi la verifica del contenuto. Una parola nella pagina o un campo nella risposta JSON che compare solo quando tutto funziona.
Imposta un timeout. Una risposta che arriva dopo 30 secondi è un errore per il visitatore, anche se finisce con un 200.
Ecco come appare per un endpoint di health check su lumenanalytics.io, testato prima a mano con curl:
curl -sS -o /dev/null -w “%{http_code} %{time_total}s\n” \
-H “Authorization: Bearer $MONITOR_TOKEN” \
https://api.lumenanalytics.io/v1/health
Se il comando stampa 200 e un tempo ragionevole, lo stesso metodo, lo stesso header e lo stesso stato atteso vanno nel monitor. In Uptimecheck, i monitor di uptime e i monitor delle API accettano metodo, header (per esempio basic auth o un bearer token), corpo, parole chiave e controlli JSON personalizzati, e segnano il controllo come fallito quando il codice di stato o la risposta non sono quelli attesi. Per progettare l’endpoint vero e proprio, leggi come creare un endpoint di health check, e consulta la checklist per il monitoraggio delle API per capire quali endpoint coprire.
Riepilogo rapido: è down?
Down: qualsiasi 5xx, un 404 su un URL che dovrebbe esistere, timeout, errori DNS e TLS, connessioni rifiutate.
Probabilmente down: un 403 o un 429 improvviso su una pagina pubblica, un 400 o un 405 su un controllo che prima passava.
Up: il codice di stato che hai configurato come atteso, con il contenuto che verifichi, in un tempo ragionevole.
In sintesi
I codici di stato sono la prima cosa che un monitor guarda e il modo più rapido per capire dove si trova un problema. Un 5xx significa che il server ha fallito, un 4xx che è cambiato qualcosa in ciò che il server accetta, e un 3xx richiede di decidere dove deve terminare il controllo. Configura ogni monitor con lo stato che deve ricevere, verifica il contenuto delle pagine importanti e fai in modo che l’avviso riporti il codice, così chi lo prende in carico sa da dove partire.
Uptimecheck controlla i tuoi siti web e le tue API fino a ogni minuto e ti avvisa quando il codice di stato o la risposta non sono quelli attesi. Provalo gratis per 14 giorni, senza carta di credito.