Torna al blog

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.

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

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:

  1. Codice di stato atteso (tipicamente 200)
  2. Tempo di risposta massimo (tipicamente 5-10 secondi)
  3. Corrispondenza di parole chiave nel contenuto (una parola chiave che deve essere nell'HTML)
  4. 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 per 7 giorni →

Condividi: Link copiato

Prova ePulz.io gratis - 7 giorni senza carta di credito.

Crea account