Build1 publisher2 min readPublished
Cloudflare's Workers Issues hands grouped production errors to Claude Code, Cursor or Devin
Cloudflare's Workers Issues, now in open beta, groups production errors from one config line and sends them to Claude Code, Cursor or Devin. Detection and dispatch happen inside Cloudflare; the fix, and any gate before it ships, live in the agent's workflow.
The Engineer · Build desk
What happened
- Because it runs inside the Workers runtime, Issues records uncaught exceptions, failed invocations, HTTP 5xx responses, console output and stack-trace logs with no SDK or wrapper.
- Each issue sent to an agent carries the error, the stack trace, logs, traces and the Worker version that was running.
- Teams configure an automation once, choosing when it runs and where the issue goes, and it fires when an issue crosses an occurrence threshold.
- User, account and session IDs set as span attributes through the runtime's OpenTelemetry API appear with every occurrence of an issue.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Whatever a Worker logs, plus any user, account or session IDs it tags, goes to the agent vendor or webhook on the other end, so logging practice now decides what a third party's agent reads.
- constraint Coverage stops at the runtime's view: an exception caught inside the handler, answered with a 200 and never logged, will not become an issue or reach an agent.
- decision Each team has to pick a threshold: set low, a flaky upstream can start agent runs on noise; set high, a real regression waits until enough requests fail.
Grouping matters more once an agent is attached. Cloudflare's example is a Worker that starts throwing after a deploy. Every failed request has its own request ID, all of them come from one bug, and Issues folds them into a single issue with a first-seen time, a count and a trend [8]. Cloudflare did not publish the rule it uses to decide that two occurrences are the same bug. If one bug is split in two, two agent workflows can start on it. If two bugs are merged, the agent gets one context describing both [4].
I think the best engineering in the release is also the least advertised. Issues flags runaway alarm conditions and code that writes large volumes of logs inside loops [7]. Neither condition throws, so a tracker that waits for exceptions would miss both [7]. Catching them depends on capture living in the runtime [5].
Cloudflare's own problem statement lists four manual steps: seeing that repeated failures are one bug, gathering the logs and traces, sending that context to an agent, and checking whether the fix worked [13]. The release covers the first three [3][11]. For the fourth, the nearest thing described is a second trigger that fires when an issue returns after a quiet period, the signal a failed fix would produce [11].
Issues starts the agent's configured workflow, anything from triage to opening a pull request [4]. To do that, the automation needs a credential for the agent account. Claude Code takes a routine ID and token, Cursor an automation webhook URL, and Devin an API token and organization ID [12]. Generic webhooks and chat or on-call tools are the other destinations [12].
Cloudflare's sample prompt shows what a written gate looks like. It tells the agent to enable Issues in cloudflare.config.ts, "show the diff and ask before deploying," and, once a fix is ready, "Ask before deploying the fix." [14] A minute after the first deploy, the agent pulls the most frequent issue with `cf observability issues list --order-by count --order desc --per-page 1` [14]. A Worker that has not failed in that minute takes the prompt's other branch: "If no issues exist, report that." [15]
Cloudflare says it can capture what happens inside a Worker but "does not know which users, accounts, or sessions matter to your application" [9]. Its answer is one call per identifier on the active span, such as `span?.setAttribute("account.id", accountId);`, using the `tracing` export from `cloudflare:workers` and no extra package [17]. With those set, a team can see whether failures cluster in one account or session before any agent runs [10].
What to watch
- Whether Cloudflare documents how Issues decides two occurrences are the same bug, since that rule sets how many agent runs one bug starts.
- The default occurrence threshold and quiet period when Issues leaves open beta, and whether they can be set per issue.
- Whether Issues adds a step that marks an issue resolved once a new Worker version stops producing it, closing the fourth manual step Cloudflare named.