Docs Autonomy
Intégrations

Notifications et webhooks

Envoyez les événements d'exécution, de problème et d'organisation par e-mail, sur Slack, dans l'application et vers des webhooks signés.

Autonomy prévient les personnes quand quelque chose se produit : une exécution échoue, une exécution trouve un nouveau problème, un membre rejoint l'organisation. Les administrateurs décident de ce que l'organisation envoie et où. Chaque membre choisit ensuite ce qui lui parvient.

PageQuiCe que vous définissez
Organization → NotificationsPropriétaires et administrateursLes événements envoyés par l'organisation, ses canaux et le canal Slack de chaque projet.
My notificationsChaque membreLes événements qui vous parviennent par e-mail, sur Slack et dans l'application, la fréquence du récapitulatif, les heures silencieuses et les filtres.
Organization → Integrations → WebhooksPropriétaires et administrateursLes endpoints qui reçoivent du JSON signé.

Événements

ÉvénementEnvoyé quand
Run startedUne exécution démarre.
Run completedUne exécution se termine, quel que soit son résultat.
Run failedUne exécution se termine sans réussir. Toujours activé pour l'organisation ; vous choisissez où vous le recevez.
New issuesUne exécution trouve un nouveau problème, ou rouvre un problème résolu, même si toutes les étapes ont réussi.
Report readyUn rapport PDF ou HTML est prêt.
Threshold breachLe taux d'échec ou la durée d'exécution dépasse vos limites.
Member joinedQuelqu'un rejoint l'organisation.
Member removedL'accès d'un membre est retiré.
Infrastructure alertProblèmes de capacité des runners ou des appareils. Administrateurs uniquement.

Run failed vous parvient toujours quelque part : si vous désactivez à la fois l'e-mail et Slack pour cet événement, l'un des deux se réactive. New issues reste silencieux quand une exécution revoit un problème déjà ouvert ; il se déclenche une fois par problème nouveau ou rouvert. Par défaut, il est envoyé sur Slack et dans l'application, pas par e-mail.

Paramètres de l'organisation

Sur Organization → Notifications :

  • Events : ce que l'organisation envoie.
  • Channels : l'e-mail pour chaque membre qui le garde activé, l'espace de travail Slack et les endpoints de webhook (Manage les ouvre).
  • Route by project : le canal Slack de chaque projet. Run failed est toujours envoyé au canal du projet et au canal par défaut. Voir Slack.

Cliquez sur Save preferences quand vous avez terminé.

Vos paramètres

Sur My notifications, choisissez pour chaque événement s'il vous parvient par Email, Slack ou In-app. Sous Digest settings :

  • Frequency : Real-time, Daily at 9:00 AM ou Weekly on Monday. Les options quotidienne et hebdomadaire regroupent vos e-mails en un seul récapitulatif.
  • Quiet hours : une plage horaire pendant laquelle rien n'est envoyé.
  • Only my runs : les événements d'exécution uniquement pour les exécutions que vous avez lancées.
  • Always notify on production failures : les échecs dans les environnements de production vous parviennent même pendant les heures silencieuses.

Chaque e-mail comporte un lien de désabonnement qui ouvre ces paramètres.

Le digest hebdomadaire de l'environnement d'un projet, avec ce qui a été exécuté, ce qui a cassé et les problèmes trouvés, est une chose distincte : vous le relisez et le publiez sur la page Digests du projet.

Webhooks

Les webhooks envoient les événements à vos propres systèmes sous forme de JSON signé.

  1. Ouvrez Organization → Integrations → Webhooks et cliquez sur Add endpoint.
  2. Saisissez l'URL de l'endpoint et choisissez ses événements.
  3. Sous Projects, ne cochez aucun projet pour recevoir les événements de tous les projets, ou cochez-en certains pour ne recevoir que les leurs. Les événements de l'organisation, comme ceux des membres et les alertes d'infrastructure, sont envoyés à tous les endpoints qui y sont abonnés.
  4. Enregistrez, puis copiez le Signing secret et envoyez un Test event.

Pour changer le secret, utilisez Roll secret : le secret actuel cesse de fonctionner immédiatement, alors mettez à jour votre récepteur. Chaque endpoint affiche son état de santé, sa dernière livraison et son historique de livraisons. Les livraisons échouées sont retentées avec un délai croissant pendant environ 24 heures. Un endpoint qui échoue continuellement est désactivé.

Le contenu envoyé

Chaque livraison est un POST avec un corps JSON :

issue.foundjson
1{2  "type": "issue.found",3  "timestamp": "2026-10-05T14:30:00.000Z",4  "data": {5    "eventKey": "issueFound",6    "label": "New issues",7    "title": "issue.found",8    "body": "New bug: Checkout total ignores the discount code",9    "ctaLabel": null,10    "ctaUrl": null,11    "runId": "...",12    "runExecutionId": "...",13    "reportId": null,14    "actorUserId": null,15    "targetUserId": null,16    "project": {17      "id": "...",18      "name": "Storefront",19      "slug": "storefront"20    },21    "environment": "Staging",22    "isProduction": false,23    "metadata": {24      "issueId": "...",25      "issueHeadline": "New bug",26      "issueTitle": "Checkout total ignores the discount code",27      "issueKind": "Bug",28      "issueStatus": "new",29      "issueUrl": "https://app.autonomyqa.com/p/storefront/issues/...",30      "projectName": "Storefront",31      "environment": "Staging",32      "runName": "Checkout with a discount",33      "runUrl": "https://app.autonomyqa.com/p/storefront/runs/..."34    },35    "createdAt": 179121060000036  }37}

type vaut l'une des valeurs run.started, run.completed, run.failed, issue.found, report.ready, threshold.breach, member.joined, member.removed et infrastructure.alert.

data.project est le projet de l'événement, ou null pour les événements de l'organisation. data.metadata ne contient qu'un ensemble autorisé d'informations : le nom de l'exécution, l'environnement, le résultat, la durée, les décomptes, les résultats des étapes et les liens ; l'identifiant, l'en-tête, le titre, le type, le statut et le lien du problème ; et les champs du seuil, du membre ou de l'alerte. Rien sur le fonctionnement interne d'Autonomy n'est envoyé.

Un événement run.failed comporte aussi data.cause, qui indique pourquoi l'exécution n'a pas réussi :

causeSignification
"app"L'exécution a échoué. Ouvrez-la pour voir quelle étape a échoué et pourquoi.
"couldnt_start"L'exécution a eu le résultat Couldn't start, par exemple parce que l'application ne s'est pas ouverte ou qu'aucun appareil de test n'était disponible. Corrigez la configuration, puis relancez.

Vérifier la signature

Les livraisons suivent Standard Webhooks. Chacune porte les en-têtes webhook-id, webhook-timestamp et webhook-signature. La signature est un HMAC-SHA256 de <webhook-id>.<webhook-timestamp>.<body> calculé avec le secret de signature de l'endpoint, envoyé sous la forme v1,<base64>. Utilisez une bibliothèque Standard Webhooks pour la vérifier, rejetez tout ce qui ne correspond pas, et rejetez les horodatages anciens pour empêcher les rejeux. Utilisez webhook-id pour ignorer une livraison déjà traitée.

Choisir quoi envoyer

Commencez par Run failed et New issues, envoyés à l'équipe responsable du parcours. N'ajoutez Run completed que pour un canal ou un système dont le rôle est de consigner chaque résultat. Un canal qui reçoit chaque exécution est un canal que personne ne lit.

Vous n’avez pas trouvé ?

On this page