2026-10-03 18:26 UTC
DANGMUAAI & Developer Tools, Decoded
BackDev Tools

Cloudflare Routes Worker Errors Straight to Your Coding Agent

Issues for Workers hit open beta September 30. It hands exceptions and the affected Worker version to a coding agent — triage them before you let it patch.

DangMua EditorialOct 03, 20263 min read
Cloudflare Routes Worker Errors Straight to Your Coding Agent

Cloudflare opened Issues for Workers in public beta on September 30. It groups recurring exceptions, server errors and error logs, then can send diagnostic context — including the affected Worker version — to a configured coding agent.

Cloudflare describes a workflow where the agent proposes a fix and the owner reviews and deploys it. The capability is the easy part. The decision it forces on you is not.

Faster to the agent is not the same as fixable

The developer analysis that prompted this framing puts the lesson plainly: it is not that "your app can maintain itself now," but that a reported failure can reach an AI faster, so you need a better decision about what the AI should do next.

The risk is specific. Classify the incident before asking for a patch, the author argues, or "make the error disappear" can quietly become "remove the rule that protected the app."

An error string alone will not get you there. As the author puts it, "Booking failed" might describe a defect, a sold-out appointment, or a temporary connection problem — and the remedy depends on which one it is.

Five incidents, five different next steps

Working from a deliberately hypothetical appointment-booking app, the author sorts failures into five classes:

  • The app broke its own promise. A booking confirms, then vanishes on refresh, reproducibly. Give the agent a repeatable example and ask for a test that fails before the repair and passes after.
  • The app correctly rejected a request. Two customers race for one slot; one gets a confusing error. The rule is working. Fix the explanation and the recovery path, not the constraint.
  • An outside service is unavailable. The booking saved, the confirmation email provider is down. A patch to booking code cannot make that provider healthy — and the author warns an eager rewrite might create a second booking while trying to resend the email.
  • The app hit an operating limit. Ten appointments import, ten thousand fail. Establish the supported workload first: do not ask the AI to disable a limit just because it interrupted a test.
  • Someone wants a different product. Multi-location, staff assignments, recurring classes. That is backlog, not maintenance.

Triage prompt before repair prompt

The practical output is a two-prompt sequence. The first asks the agent to compare the incident against the promised behavior, classify it into one of those five buckets or "unknown," show its evidence, identify any action that may already have partially succeeded — and explicitly not change code yet.

"Unknown" is treated as a useful answer, not a gap: the author notes it tells the AI to investigate rather than treating your guess as a fact.

Only after that check does the repair prompt run, and it is scoped: repair only the confirmed defect, add a regression test for the reproduced case, preserve existing business constraints and unrelated behavior, and report files changed, checks actually run, and unresolved failures.

These prompts do not make the agent infallible, the author concedes. They make its assumptions easier to see and challenge.

Worth adopting?

If you already run Workers, the beta is low-cost to try — the review-and-deploy gate stays with you. The portable part is cheaper still: the incident record and the triage-first habit work with a screenshot or a test failure, and the author notes you do not have to adopt Cloudflare's service to use them. Teams shipping without that discipline get the same errors routed to an agent faster, which is only an improvement if someone decides what the agent should do.

More from DangMua