Codici di stato HTTP spiegati: cosa significano 200, 404, 502 per il monitoraggio
· 6 min di lettura
Il codice di stato HTTP e la risposta del server: 2xx OK, 3xx redirect, 4xx errore client, 5xx errore server. Cosa significano e quali monitorare.
Categorie di risposte
- 1xx Informational - risposte transitorie, il client di solito non le nota.
- 2xx Success - la richiesta è andata a buon fine. 200 OK è il valore predefinito.
- 3xx Redirection - il client deve andare altrove. 301 permanente, 302 temporaneo.
- 4xx Client errors - il client ha inviato qualcosa di sbagliato. 404, 401, 403, 429.
- 5xx Server errors - il server ha fallito. 500, 502, 503, 504.
2xx: successo
200 OK - la risposta OK standard. Questo è lo stato "healthy" che monitori.
201 Created - tipicamente la risposta a un POST che ha creato una nuova risorsa. I client API se l'aspettano.
204 No Content - successo, ma il server non ha nulla da restituire. Gli endpoint DELETE lo usano spesso.
206 Partial Content - il server ha restituito solo una parte (range request). Per lo streaming video o i download riavviabili.
3xx: reindirizzamento
301 Moved Permanently - l'URL è cambiato in modo permanente. Google trasferisce la SEO equity al nuovo URL. Usalo durante una migrazione di dominio, una transizione da HTTP a HTTPS o un passaggio a www/non-www.
302 Found / 307 Temporary Redirect - reindirizzamento temporaneo. Google non sposta il ranking. Usalo per A/B testing, manutenzione o quando l'URL tornerà nel tempo.
308 Permanent Redirect - come 301, ma preserva il metodo HTTP (POST resta POST). Con 301, il client può convertire il metodo in GET.
304 Not Modified - il client ha una cache, il server conferma che il contenuto non è cambiato. Risparmia banda.
Per il monitoraggio: Quando controlli risposte 3xx, configura se il monitor debba seguire il redirect (follow) o considerarlo un errore. Alcuni attacchi DNS hijack si manifestano come 302 inattesi.
4xx: errore lato client
400 Bad Request - errore sintattico nella richiesta. Malformed JSON, header mancante, ecc.
401 Unauthorized - credenziali mancanti o errate. Il client deve autenticarsi.
403 Forbidden - il client è autenticato ma non ha il permesso. Attenzione: alcuni server restituiscono 403 invece di 401 per ragioni di sicurezza (per non rivelare l'esistenza della risorsa).
404 Not Found - l'URL non esiste. Nel monitoraggio di uptime delle pagine sorvegliate, un 404 è un alert (la pagina è scomparsa); 404 occasionali da visitatori esterni sono piuttosto un problema SEO (perde link equity).
405 Method Not Allowed - l'URL esiste ma non accetta il metodo dato (es. un POST a un endpoint che si aspetta GET).
408 Request Timeout - il server ha aspettato la richiesta troppo a lungo e ha chiuso la connessione.
409 Conflict - la richiesta è in conflitto con lo stato attuale (es. update di una versione non più attuale).
410 Gone - la risorsa è stata rimossa permanentemente. Per Google meglio di 404 (un segnale di non tentare di reindicizzare).
422 Unprocessable Entity - la richiesta è sintatticamente OK ma contiene dati semanticamente non validi (failed validation).
429 Too Many Requests - rate limit. Il client deve rallentare. Il server aggiunge tipicamente un header Retry-After.
5xx: errore lato server
500 Internal Server Error - errore generico. Il backend ha lanciato un'eccezione non catturata dall'applicazione. Sempre allarme per il monitoraggio.
501 Not Implemented - il server non conosce il metodo HTTP (es. un vecchio server non supporta PATCH).
502 Bad Gateway - il reverse proxy (nginx, Cloudflare) non ha ricevuto risposta dal server backend. Tipicamente il backend è caduto o è andato in timeout.
503 Service Unavailable - il server è sovraccarico o in manutenzione. Spesso con un header Retry-After. Questa è una risposta pianificata, non un crash.
504 Gateway Timeout - il reverse proxy ha aspettato il backend più del timeout. Il backend di solito gira ancora, ma risponde lentamente.
520-525 Cloudflare errors - specifici di Cloudflare. 520 = il backend ha restituito qualcosa di illeggibile, 522 = il backend non ha risposto (connection timeout), 524 = il backend ha risposto troppo lentamente (origin timeout).
Regole pratiche per l'alerting
- Alert immediato: 500, 502, 503 (se non è davvero manutenzione pianificata), 504, qualsiasi timeout
- Alert su ripetizione: un 5xx una tantum può essere una race condition; alert se lo stesso endpoint cade 2x di seguito
- Seguire il trend ascendente: una crescita a lungo termine dei 4xx può significare un broken link, uno scraper attack o un frontend rotto
- Ignorare per l'alerting: 200-399 nell'intervallo atteso (segui il tempo di risposta invece del codice)
Codice di stato + tempo di risposta = il quadro completo
Seguire solo il codice di stato non basta - il server può restituire 200 ma in 30 secondi, che dal punto di vista del cliente è un outage. Il monitoraggio di qualità combina:
- Codice di stato atteso (tipicamente 200)
- Tempo di risposta massimo (tipicamente 5-10 secondi)
- Corrispondenza di parole chiave nel contenuto (una parola chiave che deve essere nell'HTML)
- SSL valido e non vicino alla scadenza
Il fallimento di uno qualsiasi di essi = alert.
Monitoraggio con classificazione precisa degli errori
ePulz.io distingue codice di stato, tempo di risposta, corrispondenza di parole chiave e stato SSL. Per ogni controllo sono disponibili log dettagliati.
Prova ePulz.io gratis - 7 giorni senza carta di credito.
Crea account