Une erreur s’est produite sur le serveur.
Quand l’utiliser
Exceptions non gérées. Journalisez les détails, ne les divulguez pas au client.
Causes courantes et solutions
Un 500 signale une exception non gérée ou une mauvaise configuration côté serveur. Commencez par les logs au moment de la requête : stack traces de l’application, logs d’erreurs PHP ou Python, journalctl, docker logs ou CloudWatch. Causes courantes : une valeur null ou undefined, une requête de base de données en échec ou une migration non appliquée, une variable d’environnement manquante en production, une erreur de syntaxe dans .htaccess, ou de mauvaises permissions sur un script.
Rendez les 500 débogables : renvoyez un ID de requête dans un en-tête et dans le corps, journalisez-le avec la stack trace, et envoyez les erreurs à un outil de suivi comme Sentry. N’affichez jamais de stack traces aux clients en production. N’utilisez pas 500 pour les erreurs du client ; les échecs de validation relèvent des 4xx, ce qui garde les alertes sur les 5xx pertinentes. Réessayer avec un backoff aide face aux pannes passagères, mais un bug déterministe échoue à chaque fois.
Erreur serveur (5xx)
Les codes 5xx sont des erreurs serveur : la requête est peut-être correcte, mais le serveur ou un composant derrière lui a échoué. Ils méritent une alerte.
À quoi ça ressemble
HTTP/1.1 500 Internal Server ErrorComment l’envoyer
| Node.js / Express | res.status(500).end() |
|---|---|
| Python / Flask | return '', 500 |
| nginx | return 500; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/