Merci @cce66 pour la demande de fonctionnalité, ça a l’air très cool Dozzle, je ne connaissais pas 
Merci @cicoub13 pour la mention, je maintiens ce que j’avais dis à l’époque pour la partie debug, il manque clairement des briques à Gladys pour permettre un debug plus facile.
Depuis mon message en 2020, il y a eu plusieurs ajouts qui vont dans ce sens, la vue « tâches en arrière plan » par exemple :
Cette vue n’est pas encore utilisée à son plein potentiel car seul certaines parties de Gladys ont implémentés ce mécanisme, et pour l’instant aucun service ne l’a implémenté.
→ Je serais pour que l’usage de cet onglet se généralise. Tout ce qui tourne en arrière plan doit être encapsulé dans des « jobs » Gladys afin d’apparaître dans cette vue, débuggable facilement en cas de problème.
L’intégration MQTT va bientôt avoir (dans la prochaine release) un onglet « Debug MQTT », ce qui permet à l’utilisateur de voir le traffic MQTT entrant sur l’instance, pratique pour débugger quand on test :
Ce n’est qu’un exemple, mais j’aimerais que Gladys et les intégrations soient plus communicantes dans l’interface pour que l’utilisateur soit moins perdu.
Par exemple, les scènes sont durs à débugger, il faudrait qu’il y a un historique d’exécution des scènes, avec toutes les informations pour que l’utilisateur comprenne ce qu’il s’est passé en cas de soucis.
Pour revenir sur le sujet
Je suis partagé sur la demande initial de @cce66, Dozzle étant un outil clairement pour expert, pourquoi on mettrait en place (ce qui représente du travail) un outil pour le lancer facilement dans Gladys, si quelqu’un veut utiliser Dozzle, il est capable de lancer une ligne de commande non ?
Est-ce qu’aussi en terme de message, on ne veut dire aux utilisateurs Gladys: on supporte le fait d’inciter les utilisateurs à aller voir les logs ?
Après, vous me direz que je suis le premier à demander les logs aux utilisateurs chez qui il y a des bugs, et vous avez raison 
Mais j’aimerais que ça change !
