# 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é](/host/docs/concepts/confidentialite/).

## 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](/host/docs/reference/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 :

```bash
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](/host/docs/guides/depannage/).