Cloudflare Workers : l'erreur part à votre agent

Ce qui se passe

Cloudflare ouvre en bêta Issues, une surveillance des erreurs intégrée au runtime Workers. Elle regroupe les échecs de production par bogue et peut transmettre chaque incident, avec son contexte, à un agent de code.

Le constat de départ : un agent sait déjà lire des journaux, parcourir un dépôt, écrire un correctif et ouvrir une pull request. Ce qui reste à la main, c'est le lien entre ces étapes — voir que mille échecs viennent du même bogue, réunir journaux et traces, les passer à l'agent, vérifier ensuite.

Comment s'y prendre

{
  "observability": {
    "issues": { "enabled": true }
  }
}

Ni SDK ni enveloppe autour du handler. Issues enregistre alors :

• les exceptions non rattrapées et les invocations en échec ;
• les réponses HTTP 5xx ;
• la sortie de console.log() et console.error(), et tout journal qui contient une pile d'appels ;
• les alarmes qui s'emballent, et le code qui journalise en masse dans une boucle.

Chaque incident montre l'erreur, la pile d'appels quand elle existe, les journaux et traces qui l'ont précédée, la version du Worker, les détails de la requête, la première apparition, le nombre d'occurrences et la tendance.

Pour savoir si un bogue frappe un client précis, on ajoute ses propres identifiants par l'API OpenTelemetry du runtime, sans paquet en plus :

import { tracing } from "cloudflare:workers";

const span = tracing.getActiveSpan();
span?.setAttribute("account.id", accountId);

Le passage à l'agent

Une automatisation part quand un incident franchit un seuil d'occurrences, ou revient après une période calme.

L'envoi contient le résumé, l'exception, la pile d'appels ramenée aux sources, les journaux et traces d'avant et d'après, la version et le contexte ajouté. Pour creuser, l'agent peut interroger journaux et traces par le serveur MCP d'observabilité de Cloudflare. Relire la pull request, déployer et clore l'incident restent des gestes humains.

Ce que Cloudflare en dit

Activé sur Workflows, son propre moteur de traitements longs, Issues aurait fait remonter en un jour deux bogues noyés dans le trafic : une migration coincée dans une boucle de réessais sur une erreur de clé étrangère SQLite, et des suppressions d'instances qui n'aboutissaient pas, faute de rester sous la limite de sous-requêtes. Un agent interne a proposé les deux correctifs. C'est l'éditeur qui le raconte, à propos de son propre produit.

Source : Detect and send production issues straight to your agent, Cloudflare, 30 septembre 2026. Voir aussi la documentation d'Issues.