tailscale status expliqué : idle, offline et alertes

Lire tailscale status en une minute

La commande tailscale status affiche une ligne par appareil de votre tailnet, et sa cinquième colonne dit dans quel état est le lien vers cet appareil. active signifie que votre machine a envoyé des paquets à ce pair récemment. idle signifie qu'elle ne lui envoie rien en ce moment. offline signifie que le pair a perdu le contact avec le serveur de coordination de Tailscale, et un simple - désigne un pair en ligne dont les compteurs de trafic sont à zéro.

La page officielle de la CLI (validée le 30 juillet 2026 selon sa propre mention) ne définit que active, idle et -. Elle ne dit rien de offline, du suffixe last seen, du bloc # Health check: ni des messages d'une ligne qui remplacent parfois le tableau. Ce guide comble ces manques à partir du code source de Tailscale v1.104.2, la version publiée le 21 octobre 2026. Les chaînes citées ici viennent de cette version. Une autre version peut les écrire autrement.

La dernière partie construit un contrôle pour un VPS sans écran : tailscale status --json, lu par jq, qui vous prévient sur votre téléphone via ntfy. Si vous découvrez l'outil, commencez par ce qu'est Tailscale et comment il relie vos machines.

Les cinq colonnes de tailscale status

Voici l'exemple de la documentation de Tailscale, recopié tel quel. Ce n'est pas une sortie capturée par nous. Les éléments entre chevrons sont les marqueurs de leur documentation.

1           2         3           4         5
100.1.2.3   device-a  apenwarr@   linux     active; direct <ip-port>, tx 1116 rx 1124
100.4.5.6   device-b  crawshaw@   macOS     active; relay <relay-server>, tx 1351 rx 4262
100.7.8.9   device-c  danderson@  windows   idle; tx 1214 rx 50
100.0.1.2   device-d  ross@       iOS       -

La colonne 1 est l'adresse IP Tailscale de l'appareil. La colonne 2 est son nom de machine, que vous pouvez utiliser pour vous y connecter si MagicDNS est activé. La colonne 3 désigne le propriétaire, mais ce n'est pas une adresse e-mail complète. Le code de la v1.104.2 coupe l'identifiant de connexion juste après le @, d'où apenwarr@ dans l'exemple. Pour un appareil partagé avec vous, il affiche en priorité l'utilisateur qui l'a partagé, et un appareil sans utilisateur associé affiche -. La colonne 4 est le système d'exploitation de l'appareil. Tout le diagnostic se joue dans la colonne 5.

Votre propre machine figure aussi dans le tableau, car l'option --self est activée par défaut. Les pairs sont triés par nom DNS, puis par nom d'hôte, puis par première adresse IP Tailscale, puis par clé publique. L'ordre des lignes ne dit donc rien de leur état.

Que veut dire chaque état de la colonne 5 ?

Le code de la v1.104.2 construit la colonne 5 en deux temps. Il regarde d'abord si le pair est actif, puis choisit le texte. Il ajoute ensuite, à la toute fin, les compteurs tx (octets envoyés) et rx (octets reçus), mais seulement si l'un des deux n'est pas nul. La documentation dit que active et idle portent ces compteurs. C'est vrai dès que l'un des compteurs n'est pas nul, et seulement dans ce cas.

Pour un pair actif, la ligne commence par active; . Elle peut ensuite porter exit node; si ce pair est votre nœud de sortie actuel, ou offers exit node; s'il propose d'en être un. Vient enfin le chemin emprunté par les paquets :

• direct <adresse> : les paquets vont directement à l'adresse IP et au port indiqués.
• relay "<région>" : les paquets passent par un relais DERP (Designated Encrypted Relay for Packets), les relais TCP chiffrés de Tailscale. Le nom de la région est imprimé entre guillemets.
• peer-relay <adresse> : les paquets passent par un nœud de votre tailnet qui sert de relais. L'adresse a la forme ip:port:vni.

Pour un pair qui n'est pas actif, le code teste les cas dans cet ordre. Le premier qui correspond gagne :

1. idle; exit node : le pair est votre nœud de sortie actuel.
2. idle; offers exit node : le pair propose d'être un nœud de sortie.
3. idle : le pair a des compteurs tx ou rx non nuls.
4. offline suivi de la date du dernier contact : le pair n'est pas en ligne et aucun octet n'est compté.
5. - : c'est le seul cas restant, un pair en ligne, dont les compteurs tx et rx sont à zéro, qui n'est pas un nœud de sortie.

Les lignes suivantes sont des illustrations construites à partir des chaînes de format du code. Elles ne viennent d'aucune machine réelle. Les adresses et les compteurs sont inventés.

active; direct 203.0.113.10:41641, tx 52344 rx 61980
active; relay "par", tx 5120 rx 4380
active; exit node; direct 203.0.113.20:41641, tx 880412 rx 9120344
idle; tx 1214 rx 50
idle; offline, last seen 5m ago, tx 9876 rx 5432
idle; exit node; offline, last seen 2h ago
idle; offers exit node
offline, last seen 3d ago
-

Les lignes exit node concernent les machines qui font sortir votre trafic Internet. Le montage côté serveur est décrit dans le guide pour faire d'un VPS un nœud de sortie Tailscale.

La ligne relay "par" mérite une précision. La documentation parle d'un code de ville, avec fra ou nyc comme exemples. La carte DERP par défaut contient bien une région Paris, de code par (identifiant 18), à côté de fra pour Francfort et ams pour Amsterdam. Rien ne garantit pour autant que votre trafic relayé passe par Paris, même derrière une Freebox. Lancez tailscale netcheck et lisez la ligne Nearest DERP. La documentation précise que le serveur à la latence la plus faible est celui utilisé pour le trafic.

Pourquoi un pair peut-il être « active » et « offline » à la fois ?

Les deux mots ne mesurent pas la même chose. Dans le fichier ipn/ipnstate/ipnstate.go, le champ Online est commenté « whether node is connected to the control plane ». Il dit donc si l'appareil est connecté au plan de contrôle, c'est-à-dire au serveur de coordination de Tailscale qui distribue les clés et les adresses. Le champ Active signifie, selon le même fichier, qu'un paquet a été envoyé à ce pair dans les deux dernières minutes environ. Le commentaire ajoute que cette définition peut changer.

Votre machine peut donc avoir envoyé un paquet à un pair dans les deux dernières minutes alors que ce pair a perdu le contact avec le serveur de coordination. Dans ce cas, le code ajoute ; offline et la date du dernier contact à la ligne active. Ce active dit qu'un envoi a eu lieu récemment, pas que l'envoi continue. L'inverse est encore plus fréquent : un pair idle est souvent en ligne. Votre machine ne lui a simplement rien envoyé ces deux dernières minutes.

Que signifie « last seen 5m ago » ?

Quand un pair n'est pas en ligne, le code ajoute , last seen suivi d'une durée. La fonction lastSeenFmt de la v1.104.2 choisit l'unité selon l'ancienneté. Sous une heure, elle compte en minutes (last seen 12m ago). Sous 24 heures, elle compte en heures (last seen 5h ago). Au-delà, elle compte en jours (last seen 3d ago).

La durée est toujours un nombre entier, et elle vaut au moins une minute. Elle vient du champ LastSeen, qui date le dernier contact du pair avec le serveur de coordination. Ce n'est pas la date du dernier paquet reçu de lui. Si le serveur de coordination n'a fourni aucune date, le suffixe disparaît et la ligne dit seulement offline.

Notez la ponctuation si vous filtrez la sortie avec grep : le point-virgule précède offline, et la virgule précède last seen.

Pourquoi « - » ne veut pas dire « hors ligne »

La documentation dit que - signifie qu'aucun trafic n'a jamais été envoyé à cet appareil ni reçu de lui. Le code de la v1.104.2 est plus étroit : il teste seulement ps.TxBytes != 0 || ps.RxBytes != 0, c'est-à-dire les compteurs que le démon rapporte au moment de la commande. Un tiret prouve donc que ces compteurs sont à zéro, pas qu'aucun paquet n'a jamais circulé. Le code montre aussi autre chose. Un pair sans trafic qui n'est pas en ligne n'affiche pas -, il affiche offline, last seen …. Le tiret seul veut donc dire : en ligne, inactif, compteurs tx et rx à zéro, et pas nœud de sortie.

Si votre VPS affiche - en face de votre NAS, le NAS est connecté au serveur de coordination. Les compteurs de trafic entre les deux machines sont simplement à zéro. Lancez tailscale ping nas-maison pour créer un échange. Cette commande tente un ping vers l'autre appareil uniquement par Tailscale, et elle montre le chemin choisi.

Direct, relay ou peer-relay : où lire la suite

Ce guide ne refait pas le diagnostic des chemins. Si vos lignes active montrent relay alors que vous attendiez direct, ou si le débit vous déçoit, lisez le guide sur les connexions Tailscale directes ou relayées. Il couvre direct, relay et peer-relay, avec tailscale ping et tailscale netcheck pour trouver la cause.

Quand tailscale status n'affiche pas de tableau

Dans la v1.104.2, le tableau n'apparaît que si l'état du démon est Running ou Starting. Dans tous les autres états, la commande imprime un message court et sort avec le code 1 :

• Tailscale is stopped. : état Stopped. Le tunnel est arrêté. sudo tailscale up le relance.
• Logged out. : état NeedsLogin. Si une URL de connexion existe, une deuxième ligne suit : Log in at: <url>. Ouvrez cette URL dans le navigateur de n'importe quel appareil.
• Machine is not yet approved by tailnet admin. : état NeedsMachineAuth. Votre tailnet exige l'approbation des appareils, et celui-ci attend encore la sienne.
• unexpected state: <nom> : tout autre état, par exemple NoState ou InUseOtherUser.

Si vous cherchiez « tailscale you need to be approved », la phrase que tailscale status affiche dans ce cas est Machine is not yet approved by tailnet admin. Selon la page Device approval de Tailscale, un appareil en attente d'approbation ne peut ni envoyer ni recevoir de trafic sur le tailnet. Un administrateur du tailnet doit l'approuver.

Le code de sortie compte autant que le texte. tailscale status > /dev/null renvoie 0 avec un tableau et 1 avec ces messages, ce qui suffit pour un test rapide. Ce test ne voit pas un pair hors ligne, ni un avertissement de santé. Pour cela, il faut le JSON.

Le bloc « # Health check: »

Quand Tailscale connaît un problème de santé, tailscale status ajoute une ligne vide après le tableau, puis l'en-tête # Health check:, puis une ligne par message. Voici le format exact, avec un texte d'illustration à la place d'un vrai message :

# Health check:
#     - <message de santé>

La CLI ne fixe pas la liste des messages. Elle imprime ceux que le démon lui transmet dans le champ Health, alors lisez-les tels quels. Un bloc absent ne prouve pas que tout va bien. Le commentaire du champ dans le code dit : « Empty means everything is good. (or at least that no known problems are detected) ».

Cas particulier : dans l'état NoState, il n'y a pas de tableau, donc le bloc s'imprime avant le message unexpected state: NoState.

Les options de tailscale status à connaître

• --active : n'affiche que les pairs actifs.
• --header : ajoute la ligne d'en-tête IP Hostname Owner OS Status. Elle est désactivée par défaut.
• --peers=false : n'affiche que votre propre machine.
• --json : la sortie complète en JSON. L'aide de l'option prévient : « WARNING: format subject to change ».
• --web : sert l'état dans une page web, par défaut sur 127.0.0.1:8384 (option --listen).

Pour suivre l'évolution pendant un test, la commande watch relance la sortie à intervalle fixe : watch -n 2 tailscale status. Si la CLI exige sudo pour certaines commandes sur votre machine, réglez l'opérateur Tailscale pour vous en passer.

Surveiller un VPS sans écran avec tailscale status --json et jq

Sur un serveur, personne ne lit le tableau. Le JSON se prête mieux à un contrôle automatique. Il cache deux pièges qu'il faut connaître avant d'écrire le moindre script.

Premier piège : tailscale status --json sort avec le code 0 même quand Tailscale est arrêté ou déconnecté. Dans la v1.104.2, la branche JSON imprime l'état et s'arrête avant le test qui produit le code 1. Votre script doit donc lire BackendState lui-même.

Second piège : l'aide de l'option dit que le format peut changer. La plupart des champs n'ont pas d'étiquette JSON dans le code Go, donc leur nom JSON est le nom du champ Go. Un renommage dans le code renomme le champ dans la sortie. Un script qui lit .Self.Online et reçoit null ne doit jamais conclure que tout va bien. Il doit signaler un champ manquant.

Les champs à lire

• BackendState : l'état du démon. Pour un serveur, Running est le seul état sain. La v1.104.2 en connaît sept : NoState, InUseOtherUser, NeedsLogin, NeedsMachineAuth, Stopped, Starting et Running. Le commentaire du code n'en cite que six, alors traitez toute valeur inconnue comme une panne.
• Self.Online : votre VPS est-il connecté au serveur de coordination ?
• Health : une liste de messages. Elle vaut null ou [] quand rien n'est signalé, et le script doit accepter les deux.
• Peer : un objet dont les clés sont les clés publiques des pairs, pas un tableau. Parcourez-le avec .Peer[].
• Pour chaque pair : HostName, Online, LastSeen, Active, KeyExpiry et Expired.

Deux champs portent l'option omitempty : Expired et KeyExpiry. Expired disparaît quand il vaut false, et KeyExpiry n'apparaît que si une date d'expiration est connue. Leur absence est donc normale, et le script ne doit pas la traiter comme une erreur. LastSeen est commenté « only present if offline », mais il n'a pas d'option omitempty. Pour un pair en ligne, attendez-vous à la date zéro de Go, 0001-01-01T00:00:00Z. Le script ci-dessous ne s'appuie donc jamais sur sa présence.

Installez jq, puis regardez vos propres valeurs :

sudo apt update && sudo apt install -y jq curl
tailscale status --json | jq '.BackendState, .Self.Online, .Health'
tailscale status --json | jq -r '.Peer[] | .HostName + " online=" + (.Online|tostring) + " active=" + (.Active|tostring)'

Sur un nœud sain, la première commande imprime "Running", puis true, puis null ou []. La seconde imprime une ligne par pair. Notez les valeurs HostName des machines qui comptent pour vous, car le script les surveille par ce nom. Le code précise que HostName n'est pas forcément unique, alors donnez des noms distincts à ces machines.

Le script

Enregistrez ce fichier sous le nom tailscale-check. Remplacez l'URL et le jeton ntfy par les vôtres. Si vous n'avez pas encore de serveur, installez votre propre serveur ntfy pour les notifications push. ntfy reçoit un message par une simple requête HTTP POST, et le jeton d'accès passe dans l'en-tête Authorization: Bearer tk_....

#!/usr/bin/env bash
# /usr/local/bin/tailscale-check : alerte ntfy quand Tailscale va mal sur ce VPS
set -uo pipefail

NTFY_URL="https://ntfy.example.com/tailscale-vps"
NTFY_TOKEN="tk_remplacez_par_votre_jeton"
WATCH="${WATCH:-nas-maison backup-vps}"
EXPIRY_WARN_DAYS=14
STATE=/var/lib/tailscale-check/last

alert() {
  curl -fsS -m 10 \
    -H "Authorization: Bearer $NTFY_TOKEN" \
    -H "Title: Tailscale sur $(hostname)" \
    -H "Priority: high" \
    -H "Tags: warning" \
    -d "$1" "$NTFY_URL" > /dev/null
}

if ! json=$(tailscale status --json); then
  problems="tailscale status --json a échoué (voir journalctl -u tailscale-check)"
elif ! problems=$(printf '%s' "$json" | jq -r --arg watch "$WATCH" '
  def need($obj; $key; $where):
    if ($obj | type) != "object" then "objet absent : " + $where
    elif ($obj | has($key) | not) then "champ absent : " + $where + "." + $key
    else empty end;
  ($watch | split(" ") | map(select(. != ""))) as $w |
  need(.; "BackendState"; "racine"),
  need(.; "Health"; "racine"),
  need(.Self; "Online"; "Self"),
  (if has("BackendState") and .BackendState != "Running"
     then "BackendState = " + .BackendState else empty end),
  (if .Self.Online == false
     then "Self.Online = false : plus de lien avec le serveur de coordination"
     else empty end),
  (if .Self.Expired == true then "la clé de ce nœud a expiré" else empty end),
  ((.Health // [])[] | "santé : " + .),
  ([(.Peer // [])[] | .HostName] as $names |
     $w[] | select(. as $n | $names | any(.[]; . == $n) | not) |
     "pair surveillé introuvable : " + .),
  ((.Peer // [])[] | select(.HostName as $h | $w | any(.[]; . == $h)) |
     need(.; "Online"; "pair " + .HostName),
     (if .Online == false
        then .HostName + " hors ligne, LastSeen " + (.LastSeen | tostring)
        else empty end),
     (if .Expired == true then .HostName + " : clé expirée" else empty end))
'); then
  problems="sortie de tailscale status --json illisible par jq"
else
  expiry=$(printf '%s' "$json" | jq -r '.Self.KeyExpiry // empty')
  if [ -n "$expiry" ]; then
    left=$(( ( $(date -d "$expiry" +%s) - $(date +%s) ) / 86400 ))
    if [ "$left" -lt "$EXPIRY_WARN_DAYS" ]; then
      msg="clé de ce nœud : $left jours avant expiration ($expiry)"
      if [ -n "$problems" ]; then
        printf -v problems '%s\n%s' "$problems" "$msg"
      else
        problems="$msg"
      fi
    fi
  fi
fi

if [ "$problems" != "$(cat "$STATE" 2> /dev/null)" ]; then
  if alert "${problems:-Retour à la normale}"; then
    printf '%s' "$problems" > "$STATE"
  fi
fi
[ -z "$problems" ]

Ce que fait chaque bloc

• La première branche couvre l'échec de tailscale status --json lui-même, par exemple quand le démon tailscaled ne répond pas. Le message d'erreur de la CLI part dans le journal du service.
• La fonction jq need vérifie qu'un champ existe. Un champ absent produit un message comme champ absent : Self.Online. Vous recevez donc une alerte au lieu d'un faux « tout va bien ».
• Un BackendState autre que Running déclenche une alerte avec le nom de l'état, y compris un état que ce guide ne connaît pas.
• Chaque message de Health devient une ligne de l'alerte.
• Seuls les pairs listés dans WATCH sont surveillés, car un ordinateur portable éteint le soir n'est pas une panne. Pour ces pairs, le script signale un nom absent de la liste, un Online à false avec sa date LastSeen, ou une clé expirée.
• Le champ KeyExpiry de votre VPS déclenche un rappel quand il reste moins de EXPIRY_WARN_DAYS jours. Le nombre de jours change chaque jour, donc ce rappel revient une fois par jour.
• Le fichier /var/lib/tailscale-check/last garde la dernière liste de problèmes. Le script n'envoie une notification que si cette liste change, puis une dernière, « Retour à la normale », quand tout redevient sain. Si l'envoi vers ntfy échoue, le fichier reste inchangé, donc l'exécution suivante réessaie.

L'installer avec un timer systemd

Créez le service dans /etc/systemd/system/tailscale-check.service :

[Unit]
Description=Vérifie Tailscale et alerte via ntfy
After=tailscaled.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/tailscale-check

Puis le timer dans /etc/systemd/system/tailscale-check.timer :

[Unit]
Description=Lance tailscale-check toutes les 5 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

Installez le script et activez le timer :

sudo install -m 755 tailscale-check /usr/local/bin/tailscale-check
sudo install -d -m 700 /var/lib/tailscale-check
sudo systemctl daemon-reload
sudo systemctl enable --now tailscale-check.timer
systemctl list-timers tailscale-check.timer

list-timers doit montrer une prochaine exécution dans moins de cinq minutes. Le script est un service oneshot, donc systemctl status tailscale-check montre l'échec de la dernière exécution quand un problème est en cours.

Vérifier que l'alerte arrive

Ne coupez pas Tailscale pour tester, surtout si vous êtes connecté au VPS par le tunnel. Simulez plutôt un pair disparu :

sudo /usr/local/bin/tailscale-check; echo "code de sortie : $?"
sudo env WATCH=pair-de-test /usr/local/bin/tailscale-check; echo "code de sortie : $?"
sudo /usr/local/bin/tailscale-check; echo "code de sortie : $?"

Sur un nœud sain, la première commande affiche code de sortie : 0 et n'envoie rien. La deuxième envoie la notification pair surveillé introuvable : pair-de-test et affiche le code 1. La troisième envoie « Retour à la normale » et affiche de nouveau le code 0. Si la deuxième commande ne fait rien vibrer, testez ntfy seul avec curl -d "test" https://ntfy.example.com/tailscale-vps et le bon en-tête Authorization.

Clé expirée ou appareil non approuvé : que faire ?

Les clés de nœud expirent. D'après la page Key expiry de Tailscale, les nouveaux domaines ont une période d'expiration de 180 jours par défaut (la même page parle ailleurs de six mois). Sans réauthentification, les connexions vers l'appareil et depuis l'appareil cessent de fonctionner. Lisez la date de votre VPS avec tailscale status --json | jq -r '.Self.KeyExpiry'. Une réponse null signifie qu'aucune date n'est connue.

Pour renouveler la clé sur le VPS, lancez :

sudo tailscale up --force-reauth

Par prudence, lancez-la depuis une session SSH ouverte sur l'adresse publique du VPS, pas à travers le tunnel que vous êtes en train de réauthentifier. Pour un serveur, un administrateur peut aussi désactiver l'expiration de la clé de cet appareil dans la page Machines de la console d'administration.

Pour un appareil non approuvé, rien ne se règle sur la machine elle-même. tailscale status continuera d'afficher Machine is not yet approved by tailnet admin. jusqu'à ce qu'un administrateur du tailnet approuve l'appareil.

Tailscale est-il en panne, ou seulement mon nœud ?

Si vous cherchiez la page d'état du service plutôt que la commande, elle se trouve sur status.tailscale.com. Le 21 octobre 2026, elle affichait « We’re fully operational ». Elle liste des composants, dont « Coordination service » et « DERP relay servers », et propose de s'abonner aux mises à jour.

Pour distinguer une panne de Tailscale d'une panne de votre machine, comparez ce que voient vos appareils avec cette page. Les correspondances ci-dessous sont une méthode de travail, pas une règle publiée par Tailscale.

• Seul votre VPS a Self.Online à false, vos autres appareils restent en ligne, et la page est sans incident. Le problème est de votre côté : lisez journalctl -u tailscaled et le bloc # Health check:.
• Plusieurs appareils, sur des réseaux différents, passent offline en même temps, et la page signale un incident sur « Coordination service ». Le serveur de coordination est le premier suspect.
• Vos lignes active passent par relay et la page signale un incident sur « DERP relay servers ». Regardez de ce côté avant de toucher à votre configuration.
• Votre serveur de coordination est Headscale. La page de Tailscale ne dit alors rien de votre coordination, et c'est votre propre serveur qu'il faut vérifier. Le montage est décrit dans le guide pour héberger Headscale, le serveur de coordination libre compatible Tailscale.

FAQ

Que veut dire « offline, last seen 3d ago » dans tailscale status ?

Le pair n'est plus connecté au serveur de coordination de Tailscale depuis environ trois jours. La durée vient du champ LastSeen et s'exprime en minutes (m), en heures (h) ou en jours (d). Si la ligne commence par idle; offline, le pair a aussi des compteurs de trafic non nuls. Si elle commence par active, votre machine lui a envoyé au moins un paquet dans les deux dernières minutes environ, malgré sa perte de contact avec le serveur de coordination. Cela ne prouve pas que l'envoi continue.

Pourquoi tailscale status affiche « - » pour un appareil allumé ?

Dans Tailscale v1.104.2, - signifie que le pair est en ligne, que ses compteurs tx et rx sont à zéro au moment de la commande, et qu'il n'est pas un nœud de sortie. Ce n'est pas un signe de panne, et ce n'est pas non plus la preuve qu'aucun paquet n'a jamais circulé. Un pair hors ligne sans trafic affiche offline à la place. Lancez tailscale ping <nom> pour provoquer un échange et voir le chemin utilisé.

Que faire quand tailscale status répond « Logged out. » ?

Le démon est dans l'état NeedsLogin et la commande sort avec le code 1. Si une deuxième ligne Log in at: <url> apparaît, ouvrez cette URL dans un navigateur sur n'importe quel appareil pour reconnecter la machine. Sur un serveur dont la clé a expiré, sudo tailscale up --force-reauth relance l'authentification.

Peut-on se fier au code de sortie de tailscale status --json dans un script ?

Non. Dans la v1.104.2, tailscale status --json sort avec le code 0 même quand Tailscale est arrêté ou déconnecté, car la branche JSON s'arrête avant le test de l'état. Lisez BackendState et exigez Running. L'aide de l'option prévient aussi que le format JSON peut changer, donc un champ attendu qui manque doit déclencher une alerte, jamais un « tout va bien ».