Cliquez sur n'importe quelle carte sur le canevas d'un projet — app ou compagnon — pour ouvrir son panneau de détail. Il s'ouvre sur l'onglet Observability, où vivent le statut d'un déploiement, son pipeline, et ses logs.
Quand un déploiement est toujours en cours ou rencontre un problème, le haut de l'onglet montre un pipeline en 5 étapes (Initialization, Build image, Push manifest, Deploy to cluster, Live) avec une coche ou une croix sur chaque étape, plus une raison en une ligne quand l'une échoue. De là, « Fix & redeploy from the latest commit » relance le pipeline sans quitter le panneau — utile après avoir poussé un correctif, puisque la plupart des changements de configuration n'ont pas besoin d'un rebuild complet.
Logs Build, Deploy et Runtime
En descendant sous les métriques, le panneau Logs se divise en trois onglets, chacun avec son propre nombre de lignes : Build Logs (la sortie du build buildpack ou Docker), Deploy Logs (ce qui s'est passé en poussant l'image et le manifeste vers le cluster), et Runtime Logs (ce que le conteneur en cours d'exécution imprime lui-même sur stdout/stderr). Un indicateur « live » sur Runtime Logs signifie qu'il suit en temps réel, pas un instantané statique.
Rechercher et filtrer
La zone de recherche filtre l'onglet ouvert pour ne montrer que les lignes correspondantes — utile dès qu'un log dépasse quelques centaines de lignes. À côté, All / Warnings / Errors affine par niveau sans rien taper ; le compteur de lignes à droite se met à jour selon le filtre actif. Les icônes copier et télécharger récupèrent la vue actuellement filtrée, pas toujours le log complet.
Remarque. Runtime Logs n'existe qu'une fois qu'un conteneur a réellement démarré — un build qui échoue avant ce point n'aura jamais que des logs Build (et peut-être Deploy) à montrer.