Surveillez n'importe quel processus

Certaines choses tournent des heures sans que personne ne regarde : un crawl nocturne, un entraînement, une migration, un pipeline de CI, un agent qui avance dans une longue tâche. Progress Watch leur donne un endroit où rapporter, et vous donne un endroit où regarder — plus une notification quand elles se terminent.

Trois commandes depuis l'intérieur du travail

Créez une tâche là où le travail commence, rapportez dessus au fil de l'avancement, fermez-la quand c'est fini. Celle du milieu est l'appel qui va dans votre boucle, et la seule chose qui connaisse les chiffres.

Des comptes, pas des pourcentages : l'écran affiche 1200 / 50000 pages, ce qui vous dit quelque chose que 2.4% ne dit pas. Le total peut changer à mesure qu'un travail découvre de la besogne — envoyez le nouveau nombre et la barre se recalcule. La page CLI a les trois, prêtes à coller.

Quand le processus n'est pas à vous, progresswatch run "python train.py" l'enveloppe entièrement — il crée la tâche, laisse passer la sortie intacte et la ferme avec le code de sortie, si bien qu'un travail qui échoue vous notifie quand même. Il rapporte le début et la fin plutôt que des comptes, parce que rien à l'extérieur d'un processus ne sait où il en est.

Ou une requête, depuis n'importe quoi

Sous tout cela, il y a une seule requête HTTP, et c'est toute l'API. Il n'y a pas de SDK à installer ni rien à importer, car envelopper un PUT n'ajouterait rien que vous ne puissiez écrire vous-même en moins de temps qu'il n'en faut pour lire sa documentation.

La référence de l'API est la référence sur laquelle bâtir, et coller les exemples curl est le moyen le plus rapide de voir la chose marcher avant de vous engager.

Les agents rapportent leur propre travail

Un agent IA découpe un travail en étapes puis travaille longtemps sans rien à montrer. Connectez-en un en MCP et il obtient des outils pour créer une tâche et rapporter dessus : une tâche pour le travail, une sous-tâche par étape, mises à jour au fil de l'eau. MCP ne nécessite aucune installation nulle part ; pour un client qui ne le parle pas, un skill d'agent enseigne la même chose via la CLI.

L'agent décide quand le suivi en vaut la peine et à quelle fréquence rapporter. Les descriptions des outils lui disent à quoi sert une tâche, pas un calendrier à suivre.

Pas de comptes

Un espace est un conteneur de tâches, et son UUID est l'identifiant. Quiconque a le lien peut le lire et y écrire ; partager, c'est donner le lien à quelqu'un. Il n'y a rien à créer, rien où se connecter et aucun mot de passe à perdre — ce qui veut aussi dire que le lien est le seul chemin de retour vers un espace, et qu'il vaut donc d'être gardé comme un jeton d'API.

La progression n'est pas stockée

L'état courant vit en mémoire et expire tout seul. Un crawler qui rapporte chaque seconde pendant trois mois ne fait pas grossir de base de données, et il n'y a rien à nettoyer ensuite. Le compromis est délibéré : il n'y a ni historique ni graphiques, seulement ce qui se passe maintenant.

Ce qu'il ne fera pas

• Renvoyer des commandes. C'est un tableau des départs, pas un orchestrateur. Un processus rapporte ; rien ne lui rapporte.
• Garder un journal. Une ligne, la dernière, par tâche. Le stockage de logs est un problème résolu et ce n'est pas ici.
• Imbriquer sur plus d'un niveau. Une tâche peut avoir des étapes ; une étape non.

Faites-le tourner vous-même

Le serveur est open source et l'auto-hébergement, c'est un conteneur plus un Redis — voyez l'extrait Docker pour le démarrer et auto-hébergement pour le faire tourner correctement. Le service hébergé existe pour que vous n'ayez pas à le faire, pas parce que le logiciel serait bridé sans lui.