Lire les logs

Les logs répondent à deux questions : qu’est-ce que les visiteurs ont reçu, et qu’est-ce qui s’est passé pendant le build. Ce guide montre où les trouver et comment les filtrer.

Résultat attendu : tu identifies la requête ou la ligne de build à l’origine d’un problème.

Les requêtes servies

1. Ouvre l'onglet Logs du projet

   Les requêtes apparaissent en quelques secondes : la liste se met à jour toutes les 5 secondes. Pour chacune, tu vois l’heure, le statut HTTP, la méthode, le domaine, le chemin, la durée de traitement et la taille de la réponse.

2. Isole les erreurs

   Clique Erreur pour ne garder que les réponses 5xx. Clique Alerte pour les réponses 4xx. La recherche lit le chemin et le domaine.

3. Garde la vue à jour

   Suivre garde les dernières requêtes en vue. Sous la liste, un compteur donne le nombre de réponses des dernières 24 heures par classe : 2xx, 3xx, 4xx et 5xx. Sur un site très visité, il porte sur les 50 000 dernières requêtes, et le dit. La liste montre les 1 000 requêtes les plus récentes.

4. Copie ce qui t'intéresse

   Tout copier copie toutes les requêtes reçues, une par ligne. L’icône de copie ne copie que les lignes affichées.

Les requêtes ne gardent ni adresse IP, ni en-têtes, ni paramètres d’URL (la partie après ?). Elles restent sur le serveur qui sert ton site et disparaissent après 24 heures. Voir Confidentialité.

La sortie d’un build

La page de chaque déploiement affiche la sortie du build : installation, vercel build, puis publication.

• Avec l’intégration GitHub, les lignes arrivent en direct pendant le build.
• Cherche dans les lignes, ou filtre les erreurs et les alertes.
• Ouvre le run GitHub Actions pour la sortie complète, si ton build passe par GitHub.
• Tout copier copie la sortie entière. L’icône de copie ne copie que les lignes affichées.

Un long build garde ses 1000 premières lignes et ses 1000 dernières. Une ligne indique combien de lignes ont été retirées entre les deux. La cause d’un échec est presque toujours à la fin.

Les logs de build ne restent pas toujours. Ils sont effacés 30 jours après un build annulé, 90 jours après une erreur, 180 jours après une preview et 1 an après une production. Un projet garde les logs de ses 20 derniers déploiements : au-delà, ils sont effacés dans l’heure. Ceux de la production en ligne restent. Une fois effacés, la page du déploiement affiche « Logs effacés ». Voir Limites.

Suivre un déploiement depuis le terminal

vercel deploy suit la publication jusqu’à la fin, pendant 9 minutes au plus, puis rend la main :

vercel --api https://api.host.hgdc.ch deploy --prod

Si ça ne marche pas

• Un build n’a pas de sortie : il est peut-être en file, ou il a été annulé avant de démarrer. Vérifie l’état du déploiement.
• Un problème de page n’apparaît pas dans les logs de requêtes : les requêtes sont gardées 24 heures seulement. Reproduis le problème, puis regarde tout de suite.
• « Les logs sont indisponibles pour le moment » : le serveur des sites ne répond pas. La page réessaie seule toutes les 5 secondes.
• Pour une erreur de build, commence par la première ligne d’erreur du filtre Erreur, puis remonte la sortie jusqu’à elle. Voir Dépannage.