Journaux d’exécution
L’historique d’exécution par workflow — chaque exécution avec son statut, sa chronologie et sa source de déclenchement, dépliable en un journal par étape. À lire quand une exécution a échoué ou s’est comportée bizarrement.
3 min de lecture
Les journaux d’exécution sont l’historique d’un seul workflow. Chaque fois qu’un déclencheur se lance, Tale ouvre un enregistrement d’exécution et y écrit au fil de l’exécution — statut, chronologie, l’entrée reçue et ce que chaque étape a consommé et produit. L’onglet Exécutions est la surface de débogage vers laquelle chaque autre page des automatisations pointe quand quelque chose a mal tourné.
La vue liste
Une ligne par exécution, la plus récente en premier. La barre d’outils porte Rechercher par ID d'exécution, un Filtre et un sélecteur de plage de dates.
| Colonne | Description |
|---|---|
| ID d’exécution | Identifiant stable de l’exécution — l’icône de copie le met dans le presse-papiers. |
| Statut | En attente, En cours, Terminée ou Échouée — plus En attente de saisie quand une exécution est bloquée sur un humain, et En pause pendant un débogage pas à pas. |
| Démarrée le | Heure de départ, montre en main, à la milliseconde. |
| Durée | Du départ à la fin ; vide tant que l’exécution est en cours. |
| Déclenchée par | Le chemin qui a démarré l’exécution — une planification, un webhook, un événement ou un test depuis l’éditeur. |
L’exécution dépliée
Déplie une ligne et l’enregistrement s’affiche en JSON : les métadonnées d’exécution (statut, chronologie, source de déclenchement et l’erreur s’il y en a une), les métadonnées portées par le déclencheur, les variables d’entrée et le journal — une entrée par étape exécutée avec ses entrées, ses sorties et son statut. Une étape échouée porte la chaîne d’erreur qui l’a tuée. Lis le journal de haut en bas et l’exécution se raconte à nouveau ; l’entrée dont le statut bascule est l’étape qui s’est mal comportée.
Nouvelles tentatives et relances
Les échecs transitoires se retentent tout seuls. L’onglet Configuration du workflow fixe le défaut — Nombre max de tentatives et Backoff (ms) — et chaque étape peut le surcharger dans sa propre config.
Une exécution qui échoue au-delà de son budget de tentatives reste Échouée pour la piste d’audit ; pour réessayer, ouvre Tester le workflow dans l’éditeur, colle l’entrée copiée depuis le bloc de variables de l’exécution échouée et clique sur Exécuter. La relance est une exécution neuve avec son propre ID.
Une session de débogage de bout en bout
Un rapport quotidien n’est pas arrivé. Ouvre le workflow, passe sur Exécutions et filtre sur les échecs du jour — l’exécution fautive est en haut. Déplie-la : le journal montre que l’étape de synthèse a échoué sur un timeout, et ses entrées portent le prompt reçu. Corrige la cause, relance depuis le panneau de test avec la même entrée, et regarde la nouvelle exécution se terminer avant de faire confiance à la planification de demain.
Où cela s’inscrit
Les journaux d’exécution sont le reçu que chaque workflow laisse derrière lui. Associe-les aux déclencheurs pour le coup d’envoi qui a ouvert chaque enregistrement, et aux journaux d’audit pour la trace à l’échelle de l’org de qui a changé quoi.