• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Gestion des erreurs grâce à l’expérience de conception visuelle
Par défaut, lorsqu’une action signale une erreur, Automation arrête complètement le flux de travail du runbook. Cela est dû au fait que la valeur par défaut de la propriété `onFailure` pour toutes les actions est `Abort`. Vous pouvez configurer la façon dont l’Automatisation gère les erreurs dans le flux de travail de votre runbook. Même si vous avez configuré la gestion des erreurs, certaines erreurs peuvent tout de même entraîner l’échec d’une automatisation. Pour de plus amples informations, veuillez consulter [Résolution des problèmes liés à Systems Manager Automation](automation-troubleshooting.md). Dans l’expérience de conception visuelle, vous configurez la gestion des erreurs dans le panneau **Configuration**.
![\[Options de gestion d’erreur\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/visual_designer_error_handling.png)
## Réessayer l’action en cas d’erreur
Pour réessayer une action en cas d’erreur, spécifiez une valeur pour la propriété **Tentatives maximum**. La valeur par défaut est 1. Si vous spécifiez une valeur supérieure à 1, l’action n’est pas considérée comme ayant échoué tant que toutes les tentatives n’ont pas échoué.
## Délais
Vous pouvez configurer un délai d’attente pour les actions afin de définir le nombre maximum de secondes pendant lesquelles votre action peut s’exécuter avant d’échouer. Pour configurer un délai d’attente, entrez le nombre de secondes pendant lesquelles votre action doit attendre avant qu’elle n’échoue dans la propriété **Délai en secondes**. Si le délai est expiré et que l’action a une valeur de `Max attempts` qui est supérieure à 1, alors l’étape n’est pas considérée comme ayant expirée jusqu’à ce que les tentatives soient terminées.
## Actions ayant échoué
Par défaut, lorsqu’une action échoue, Automation arrête complètement le flux de travail du runbook. Vous pouvez modifier ce comportement en spécifiant une valeur alternative pour la propriété **En cas d’échec** des actions de votre runbook. Si vous souhaitez que le flux de travail passe à l’étape suivante du runbook, choisissez **Continuer**. Si vous souhaitez que le flux de travail passe à une autre étape ultérieure du runbook, choisissez **Étape**, puis entrez le nom de l’étape.
## Actions annulées
Par défaut, lorsqu’une action est annulée par un utilisateur, Automation arrête complètement le flux de travail du runbook. Vous pouvez modifier ce comportement en spécifiant une valeur alternative pour la propriété **Annuler** des actions de votre runbook. Si vous souhaitez que le flux de travail passe à une autre étape ultérieure du runbook, choisissez **Étape**, puis entrez le nom de l’étape.
## Actions critiques
Vous pouvez désigner une action comme *critique*, ce qui signifie qu’elle détermine le statut global des rapports de votre automatisation. Si une étape portant cette désignation échoue, Automation signale l’état final comme `Failed` indépendamment du succès des autres actions. Pour configurer une action comme critique, laissez la valeur par défaut comme **Vrai** pour la propriété **Est critique**.
## Fin des actions
La propriété **Est fin** arrête une exécution d’automatisation à la fin de l’action spécifiée. La valeur par défaut pour cette propriété est `false`. Si vous configurez cette propriété pour une action, l’automatisation s’arrête, que l’action réussisse ou échoue. Cette propriété est le plus souvent utilisée avec des actions `aws:branch` destinées à gérer des valeurs d’entrée inattendues ou non définies. L’exemple suivant montre un runbook qui attend un état d’instance tel que `running`, `stopping`, ou `stopped`. Si une instance est dans un état différent, l’automatisation prend fin.
![\[L’expérience de conception visuelle est l’exemple final\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/visual_designer_is_end_example.png)