Cloudflare has introduced Issues, built-in error monitoring for Cloudflare Workers, now in open beta. The feature groups repeated exceptions, 5xx responses and error logs into a single issue, then sends the error, stack trace, logs, traces and Worker version to a configured coding agent. It matters because the handoff between detecting a production failure and having an agent investigate it has remained manual: someone still has to recognize that repeated failures share a cause, gather the relevant telemetry, hand it to an agent and check whether the fix worked.
Setup requires one line of configuration, with no SDK to install or application wrapper to add. Issues are built into the Workers runtime. Once enabled, the system records uncaught exceptions, failed invocations, HTTP 5xx responses, output from console.log() and console.error(), and logs containing a stack trace. It also flags runaway alarm conditions and code that writes large volumes of logs inside loops. Cloudflare gives the example of a Worker whose handler starts throwing after a deployment: every failed request carries a different request ID, but Issues groups them and shows when the error first appeared, how many times it has occurred and whether it is becoming more frequent. Opening an issue shows the error, a stack trace when available, the logs and traces leading up to it, the Worker version, request details and the issue’s trend over time.
Cloudflare notes it can capture what happened inside the Worker but does not know which users, accounts or sessions matter to an application. Developers can add those identifiers through the Worker runtime’s built-in OpenTelemetry API without installing another package, using tracing.getActiveSpan() and setAttribute calls for values such as user.id, account.id and session.id. Those identifiers appear with each occurrence, so an issue shows whether failures are concentrated in one account or session before it is sent to an agent.
Issues can be routed to an agent through Automations. A developer configures an automation once, and when an issue crosses an occurrence threshold or returns after a quiet period, Issues sends it to the chosen destination. Supported built-in coding agents include Claude Code, connected with a routine ID and token; Cursor, connected with an automation webhook URL; and Devin, connected with an API token and organization ID. Issues can also go to generic webhooks for a custom agent or HTTPS endpoint, or to chat and incident management tools. The payload includes the failure summary and diagnostic context: the exception, error, source-mapped stack trace, leading and trailing logs and traces, Worker version and any application context added by the developer. For deeper investigation, an agent can connect separately to Cloudflare MCP to query related logs and traces, propose code and test changes and open a pull request. Cloudflare says the developer stays in control: review the pull request, deploy the fix and mark the issue resolved.
Cloudflare tested Issues on its own production systems through Workflows, a primitive for long-running, multi-step applications built entirely on the Workers platform. Within a day of turning it on, the team found two problems hidden inside a large volume of traffic. A Workflows control plane migration repeatedly hit a SQLite foreign key error when applying migrations in an edge case, leaving it stuck in a retry loop. Separately, during deletion of Workflow instances, an edge case could exceed a Workers subrequest limit and prevent the deletion from finishing. Cloudflare says its automation setup sent both issues directly to Cloudflare OS, which followed the errors into the Workflows code and proposed a fix for both.
To get started, developers set observability.issues.enabled to true in their wrangler.jsonc file and set up a first automation in the Cloudflare dashboard to send issues to an agent, webhook, incident management tool or chat platform. Cloudflare says an agent handling setup can also use the new cf CLI to inspect issues and create automations. What remains unproven is how the grouping and automation thresholds perform outside Cloudflare’s own traffic; the open beta is the first broad test.
