Cloudflare’s Issues feature groups repeated failures in Workers and can send their diagnostic context to a coding agent. Workers runs app code without requiring you to manage a server. Cloudflare announced Issues in open beta.

What Issues does

Issues watches a Worker for uncaught exceptions, failed requests, server errors (HTTP 5xx responses), and console error output. Cloudflare also lists logs that contain a stack trace, which is the list of code steps leading to a crash.

It then groups repeats. If one bug causes 400 failed requests after a deploy, you see one issue with a count and a trend, not 400 separate log lines.

How the agent handoff works

You can connect Issues to an agent. Cloudflare lists built-in integrations for Claude Code, Cursor, and Devin, plus generic webhooks (a URL that receives a message when something happens) and chat tools.

When an issue crosses your configured threshold or returns after a quiet period, Cloudflare says the agent receives the exception, a stack trace mapped back to your source code, logs and traces from before and after the failure, the Worker version, and application context you supplied. The agent can then triage, query more data, or open a pull request, depending on how you set it up.

Cloudflare’s own framing keeps you in charge: you review the pull request, deploy the fix, and mark the issue resolved.

How to turn it on

Cloudflare says one line of configuration does it. In your wrangler.jsonc file (the settings file for a Worker), set observability.issues.enabled to true. No extra instrumentation is required, because the feature lives in the Workers runtime.

Cloudflare’s post also offers a prompt for your agent that uses its new cf command-line tool. The prompt tells the agent to enable Issues, show you the change, and ask before deploying. That ask-first step is worth keeping.

What to watch

Your logs travel. Whatever your Worker logs can end up in front of the agent and the service behind it. Diagnostic logs can include email addresses, tokens or customer data. Remove sensitive values from logs before enabling the handoff. Review the logs and confirm retention and access settings before connecting an agent.

An agent can open pull requests on its own. That is the point of the feature, and also the risk. A fix that silences an error is not always a correct fix.

Check beta access and charges. Confirm the terms for your account before relying on Issues for production monitoring.

Test the handoff on a disposable Worker

Use a disposable Worker with no real data or production bindings. Add a harmless error, enable Issues and trigger it a few times. Judge Issues on these measures:

  • Grouping: do the repeats show up as one issue with the right count?
  • Context: does the agent’s pull request point at the actual faulty line without you pasting any logs?
  • Correctness: does the proposed fix remove the bug without changing unrelated code?
  • Effort: how many corrections did you have to make before merging?

If the agent needs several rounds of correction, use a reporting-only workflow and fix the bug yourself.

End of article