Cloudflare launched Issues, a feature for monitoring errors inside Cloudflare Workers, currently available in an open beta release. The feature groups recurring failures into a single issue, then allows its details to be sent to a coding agent to continue the investigation, suggest a fix, and open a pull request.
Cloudflare is targeting a practical gap in the production-failure handling cycle: agents can query observability data, navigate a code repository, write tests, and modify code, but connecting these steps required human intervention to collect logs and traces and verify that multiple failures resulted from the same fault.
What does Issues monitor?
The feature operates from within the Workers environment and does not require installing an SDK or adding a wrapper to the application. After it is enabled, it records uncaught exceptions, failed invocations, 5xx HTTP responses, console.log() and console.error() output, as well as logs that include a stack trace. It also detects repeatedly triggered alert conditions and the writing of large amounts of logs inside loops.
Rather than displaying every failed request as a separate case, Issues groups similar errors and shows when they first appeared, how many times they occurred, and whether their rate is increasing. It displays the issue, the call stack when available, preceding and following logs and traces, the Worker version, request details, and the issue’s trend over time.
Adding application context to the investigation
Developers can use the OpenTelemetry interface built into the Workers environment to attach identifiers such as the user, account, and session. This data appears with each occurrence, helping determine whether the failure is concentrated in a particular account or session before it is sent to the agent.
From the monitoring dashboard to the coding agent
Automation can be configured to trigger sending when an issue exceeds a specified threshold of occurrences or returns after a quiet period. Cloudflare supports connecting Claude Code through a routine ID and token, Cursor through a webhook URL, and Devin through an API token and organization ID, in addition to general webhooks, chat systems, and incident management systems.
The sent context includes a failure summary, the exception, the call stack after being mapped to the source, logs and traces, the Worker version, and the application context added by the developer. For a deeper investigation, the agent can be separately connected to Cloudflare MCP to query related logs and traces, suggest code and test changes, and open a pull request.
What changes in practice?
Issues reduces the manual steps between discovering a failure and investigating it, but it does not make the fix fully automated. Reviewing the pull request, deploying the change, and marking the issue as resolved remain under the team’s control. Results also depend on the context added by the application and on the selected operating settings and thresholds.
Cloudflare tested the feature on Workflows, a component for long-running, multi-step applications built on Workers. Within one day, the automation helped discover two issues: a retry loop during a control-plane migration caused by a foreign-key-related SQLite error, and a deletion operation that did not complete because of exceeding the Workers subrequest limit. The automation sent both issues to Cloudflare OS, which traced the errors in the Workflows code and suggested two fixes.
To get started, observability.issues.enabled must be enabled in the wrangler.jsonc file, followed by configuring the first Automation from the Cloudflare dashboard to choose the issue destination, whether an agent, webhook, incident management tool, or chat platform.