Codici di stato HTTP spiegati: cosa significano 200, 404, 502 per il monitoraggio

In breve: Un codice di stato HTTP è un numero a tre cifre con cui il server risponde a ogni richiesta. Il gruppo dice la categoria: 2xx = OK, 3xx = redirect, 4xx = errore client, 5xx = errore server. Dal punto di vista del monitoraggio uptime ci interessano soprattutto le anomalie 5xx e 4xx.

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 default.
• 3xx Redirection - il client deve andare altrove. 301 permanent, 302 temporaneo.
• 4xx Client errors - il client ha mandato qualcosa di sbagliato. 404, 401, 403, 429.
• 5xx Server errors - il server ha fallito. 500, 502, 503, 504.

2xx: successo

200 OK - risposta OK standard. Questo è lo stato "healthy" per cui monitori.

201 Created - tipicamente 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 streaming video o download resumible.

3xx: reindirizzamento

301 Moved Permanently - l'URL è cambiato permanentemente. Google trasferisce SEO equity al nuovo URL. Usare durante migrazione di dominio, transizione da HTTP a HTTPS, passaggio a www/non-www.

302 Found / 307 Temporary Redirect - reindirizzamento temporaneo. Google non sposta il ranking. Usare 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). Il 301 può essere convertito a GET dal client.

304 Not Modified - il client ha cache, il server conferma che il contenuto non è cambiato. Risparmia banda.

Per il monitoraggio: Quando controlli risposte 3xx configura se il monitor deve 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 sbagliate. Il client deve autenticarsi.

403 Forbidden - il client è autenticato ma non ha permesso. Attenzione: alcuni server restituiscono 403 invece di 401 per ragioni di sicurezza (non rivelare l'esistenza della risorsa).

404 Not Found - l'URL non esiste. Non conta per il monitoraggio, ma sì per SEO (perde link equity).

405 Method Not Allowed - l'URL esiste ma non accetta il metodo dato (es. POST a endpoint che si aspetta GET).

408 Request Timeout - il server ha aspettato troppo la richiesta e ha chiuso la connessione.

409 Conflict - la richiesta è in conflitto con lo stato attuale (es. update di una versione che non è più attuale).

410 Gone - la risorsa è stata rimossa permanentemente. Meglio di 404 per Google (segnale di non tentare di reindicizzare).

422 Unprocessable Entity - la richiesta è sintatticamente OK ma contiene dati semanticamente invalidi (failed validation).

429 Too Many Requests - rate limit. Il client deve rallentare. Il server tipicamente aggiunge l'header Retry-After.

5xx: errore lato server

500 Internal Server Error - errore generico. Il backend ha lanciato un'eccezione non catturata dall'applicazione. Sempre alarme per il monitoraggio.

501 Not Implemented - il server non conosce il metodo HTTP (es. 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 in timeout.

503 Service Unavailable - il server è sovraccarico o in manutenzione. Spesso con 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, solo lento.

520-525 Cloudflare errors - specifico per Cloudflare. 520 = backend ha restituito qualcosa di illeggibile, 522 = backend non ha risposto (connection timeout), 524 = 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 race condition; alert se lo stesso endpoint cade 2× di seguito
• Seguire trend ascendente: crescita a lungo termine dei 4xx può significare broken link, scraper attack o frontend rotto
• Ignorare per l'alerting: 200-399 nel range atteso (seguire response time invece del codice)

Codice di stato + response time = 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:

1. Codice di stato atteso (tipicamente 200)
2. Response time massimo (tipicamente 5-10 secondi)
3. Keyword match nel contenuto (parola chiave che deve essere nell'HTML)
4. SSL valido + non prima della fine validità

Caduta di uno qualsiasi = alert.

Monitoraggio con precisa classificazione degli errori

ePulz.io distingue codice di stato, response time, keyword match e stato SSL. Log per ogni controllo.

Prova per 7 giorni →