Logs : les builds et les requêtes de votre site
Les journaux vous disent ce qui s'est passé et quand : chaque génération et chaque publication du projet, et chaque requête qui a exécuté le code propre à votre site durant la dernière journée. Servez-vous-en pour comprendre pourquoi un formulaire, une tâche planifiée ou une page ne se comporte pas comme prévu.
Deux types de journaux
| Voir | Ce qu'il affiche | Jusqu'où remonter |
|---|---|---|
| Builds | Chaque construction, modification et publication de ce projet, avec les étapes de chacune. | Les 40 derniers |
| Requests | Les requêtes et les erreurs du site, les plus récentes d'abord. | Les dernières 24 heures, 100 à la fois au maximum |
Les tâches planifiées et les webhooks gardent leurs propres journaux, pendant trente jours : Runs sous Tâches planifiées et Deliveries sous Webhooks. Les messages envoyés par vos formulaires sont conservés sous Settings, Forms.
Builds
Chaque entrée indique ce qui a été demandé (dans les mots de la demande), qui l'a demandé, quand, et combien de temps cela a pris. Lorsqu'aucune personne ne l'a lancée, elle indique Briks. À droite se trouve son statut :
| Statut | Signification |
|---|---|
| Waiting | En attente derrière d'autres tâches. |
| Running | En cours. |
| Done | Terminé. |
| Failed | Il s'est arrêté avant la fin. |
| Stopped | Elle a été arrêtée avant la fin. |
Cliquez sur une entrée pour voir ses étapes, chacune avec l'heure à laquelle elle a eu lieu. Une étape qui a échoué s'affiche en rouge. Une entrée en échec se termine par : It did not finish. Nothing on the live site changed, and no credits were charged for it.
Pour suivre le même travail en direct, avec l'aperçu à côté, utilisez le studio : voir Suivre une création.
Demandes
Requests affiche les appels qui ont exécuté le code propre à votre site : ses routes /api, et les visites de pages pendant qu'un test A/B répartit les visiteurs entre deux versions. Les pages ordinaires, les images et les fichiers sont servis tels quels, ils n'apparaissent donc pas. Les messages envoyés par un formulaire de contact non plus : ils vont directement à Briks, sans passer par le code de votre site.
Chaque ligne indique l'heure, la méthode et le chemin (GET demande quelque chose, POST envoie quelque chose), la durée en millisecondes, et le statut avec lequel le site a répondu, ou l'absence de réponse. Les lignes que le code de votre site a écrites lui-même affichent leur message et un niveau tel que error ou warning. Cliquez sur une ligne pour voir le message complet, la date et l'identifiant de la requête.
| Statut | Ce que cela signifie |
|---|---|
| 2xx, comme 200 | Ça a fonctionné. |
| 4xx, comme 400 ou 404 | La requête a été refusée : il manquait quelque chose ou une information était erronée, ou rien n'existe à cette adresse. |
| 5xx, comme 500 | Le code du site a échoué en répondant. |
Filtres
| Filtrer | Choix | Utilisez-le pour |
|---|---|---|
| Search | N'importe quels mots : un chemin, un message, un identifiant de requête | Trouvez une route ou une erreur précise. |
| Level | All levels, Errors, Warnings | Afficher uniquement les problèmes signalés par le code. |
| Status | Any status, Succeeded, 4xx, 5xx | Affichez uniquement les requêtes refusées ou en échec. |
Réglez-les et appuyez sur Show. L'adresse de la page les conserve, vous pouvez donc mettre en favori une vue filtrée. No requests in the last day signifie que rien n'a exécuté le code du site en 24 heures. Si la page indique Logs cannot be read right now, réessayez dans une minute.
Diagnostiquer un formulaire défaillant
Cherchez l'entrée
Où : Settings, Forms
Chaque message envoyé par un visiteur est conservé ici, les 100 derniers étant affichés à l'écran. Chacun indique quand il est arrivé et depuis quelle page, puis emailed, not emailed ou preview.
Si c'est écrit aperçu
Où : Settings, Forms
Le site n'a pas été publié en production : les entrées sont donc conservées, mais pas envoyées par e-mail. Voir Publier en production.
Si l'état indique « envoyé par e-mail » mais que rien n'est arrivé
Où : Your inbox
Les envois vont à la personne qui a créé le projet, ou au premier Owner de l'espace de travail si cette personne est partie. Vérifiez cette boîte de réception, y compris le dossier des spams.
S'il n'est pas là du tout
Où : The live site
Le message n'est jamais arrivé chez Briks. Envoyez-en un vous-même. Si le formulaire répond que trop de messages ont été envoyés d'ici, une limite a été atteinte : jusqu'à 5 messages par visiteur en 10 minutes, et jusqu'à 300 par jour pour le site.
Si un autre outil doit l'avoir
Où : Settings, Webhooks, Deliveries
Réglez Status sur Failed et appuyez sur Show. Ouvrez l'envoi pour lire ce que l'autre outil a répondu, puis Send again une fois le problème corrigé.
Diagnostiquer une tâche planifiée en échec
Lire l'exécution
Où : Settings, Scheduled tasks, Runs
Ouvrez l'exécution échouée. Elle montre ce que l'adresse a répondu, par exemple answered 500, et le début de la réponse.
Trouver l'erreur
Où : Settings, Logs, Requests
Si la tâche appelle une route de votre site, cherchez son chemin, par exemple
/api/daily-summary, et réglez Level sur Errors. Le message indique ce qui s'est mal passé dans le code.Demandez la correction
Où : Studio
Collez l'erreur dans le chat du studio avec une phrase sur la tâche : La route du résumé quotidien échoue avec cette erreur chaque matin. Voir Faire des modifications.
Réessayer
Où : Settings, Scheduled tasks
Une fois la correction publiée, ouvrez les trois points de la tâche et choisissez Run now. Le résultat s'affiche aussitôt.
Une exécution marquée Skipped n'a pas échoué : les appels du jour pour le projet étaient épuisés. Les exécutions reprennent après minuit UTC. Les limites des offres sont sur la page Tâches planifiées.
Diagnostiquer une page lente
Requests mesure tout ce qui exécute le code de votre site. C'est donc là qu'il faut regarder quand une page qui charge son contenu depuis les routes du site semble lente. Les applications et les tableaux de bord fonctionnent généralement ainsi.
Ouvrez la page et notez l'heure
Où : The live site
Chargez vous-même une fois la page lente, pour que ses requêtes figurent parmi les plus récentes.
Lire les durées
Où : Settings, Logs, Requests
Regardez les millisecondes à côté de chaque requête faite à ce moment-là. Une route qui prend plusieurs secondes quand les autres en prennent quelques centaines de millisecondes est la coupable.
Affinez votre choix
Où : Settings, Logs, Requests
Recherchez le chemin de cette route pour voir si elle est toujours lente ou seulement parfois, et si Warnings ou Errors apparaissent à côté.
Demander une correction
Où : Studio
Dites au studio quelle route est lente et à quel point, avec la page qu'elle dessert.
Si rien de lent n'apparaît, le délai ne vient pas du code de votre site. Les pages, images et fichiers sont servis tels quels : regardez donc ce que la page contient, comme de grandes images ou une vidéo, et décrivez dans le studio ce qui vous semble lent.
Exemple concret : une application de réservation qui n'enregistrait plus
Aucune nouvelle réservation n'était arrivée depuis le matin, alors que le téléphone n'arrêtait pas de sonner : des gens disaient que le formulaire ne faisait rien.
Sous Requests, avec Status réglé sur 5xx, chaque POST /api/bookings depuis 9:12 a répondu 500. La ligne d'erreur à côté indiquait qu'un champ obligatoire était manquant.
Depuis ce matin, chaque réservation échoue avec une erreur 500 sur /api/bookings. Le journal indique que le champ de la taille de l'animal est manquant. Nous avons retiré ce champ du formulaire hier.
La modification a été publiée, et la réservation suivante sous Requests a reçu la réponse 200.