Cloudflare Launches Issues for Built-In Workers Error Monitoring and Automated Agent Handoff

Cloudflare Launches Issues for Built-In Workers Error Monitoring and Automated Agent Handoff Cloudflare has introduced Issues in open beta, an error-monitoring system built directly into the Workers runtime. It automatically groups failures, captures execution context, and forwards structured incident data directly to AI coding agents via automations. Issues requires no SDK or application wrapper, enabling error tracking via a single configuration line in the Workers runtime. The system captures uncaught exceptions, failed invocations, HTTP 5xx responses, console output, runaway alarms, and high-volume loop logs. Failures originating from the same root cause are grouped to track occurrence counts, trends, and first-seen timestamps. Built-in OpenTelemetry APIs allow custom identifiers like user or session IDs to be embedded directly into error occurrences. Runtime-Level Error Monitoring and Grouping Issues is integrated directly into Cloudflare Workers runtime, removing the need for external SDKs or wrappers. When activated through configuration, it monitors uncaught exceptions, 5xx HTTP responses, invocation failures, and specific logging anomalies such as loop-based logging or runaway alarms. Instead of treating every failed request independently, Issues aggregates matching failures, showing overall frequency, initial appearance times, and error progression over time alongside source-mapped stack traces. Custom Context and Automated Agent Integration Developers can enrich failure reports with user, account, or session identifiers using the runtime's native OpenTelemetry API without extra packages. To streamline remediation, Automations route diagnostic context—including logs, stack traces, and Worker versions—directly to coding agents when occurrence thresholds are met. Coupled with Cloudflare MCP, agents can query related traces to suggest code changes and submit pull requests while human operators retain deployment approval. Internal Production Testing on Cloudflare Workflows Cloudflare evaluated Issues internally on Cloudflare Workflows, an architecture built entirely on Workers. Within one day of enablement, the system surfaced two hidden bugs from large traffic volumes. Automated alerts routed the diagnostic information to Cloudflare OS, which traced the underlying code and generated pull request fixes for both incidents.

Cloudflare Workers推出Issues功能：内置错误监控并直连AI Agent Cloudflare宣布为Cloudflare Workers推出内置错误监控功能Issues（现处于公开公测阶段）。该功能直接集成于Workers运行时，无需额外SDK即可自动聚合生产环境故障，并可通过自动化流程直接交由AI Agent进行分析与修复。 Issues无需安装SDK或包装应用，仅需一行配置即可内置捕获未捕获异常、5xx响应、日志与堆栈跟踪等。 系统可自动将同源错误聚合为一个Issue，并支持通过内置OpenTelemetry API注入用户、账户等业务标识。 通过Automations可设置阈值，自动将诊断上下文发送给编码Agent，或配合Cloudflare MCP深入查询日志并提PR。 Cloudflare Workflows内部团队通过该功能与Cloudflare OS联动，在上线一天内排查并修复了隐藏在高流量中的两处异常。 运行时内置的聚合与监测机制 Issues集成于Workers运行时，无需额外SDK或应用包装器即可启用。它能捕获未捕获异常、调用失败、5xx错误、控制台日志输出及堆栈信息，并对失控告警或循环写日志等异常行为报警。针对单次部署引发的大量报错，Issues会自动进行同源聚合，展示首次出现时间、发生频率及趋势；开发者还可利用内置的OpenTelemetry API附加账户或会话等关键上下文。 直连Agent的自动化诊断流程与实战 传统模式下开发者需要手动复制堆栈并拼接上下文，而Issues的Automations功能可在错误达到阈值或平息后复发时，直接向Agent发送包含异常、源码映射堆栈及前后日志的诊断包。结合Cloudflare MCP，Agent能自主查询遥测数据并提交修复PR。Cloudflare Workflows团队在自身生产系统中开启该功能后，一天内便将两起偶发故障直接交由Cloudflare OS定位代码并给出了修复方案。 启用方式与控制权限 开发者只需在配置文件（如wrangler.jsonc）中将observability.issues.enabled设为true，或借助新的cf CLI由Agent辅助完成配置与排查。在整个自动化排查和修复环节中，开发者依然拥有最终控制权，需审核PR并部署修复后再标记问题解决。

As agents help us build more complex applications, both humans and agents need a better way to stay on top of what goes wrong in production. Coding agents can already query observability data, navigate a repository, change code, write tests, and open a pull request. What remains manual is connecting those steps: recognizing that repeated failures come from the same bug, gathering the relevant logs and traces, sending that context to an agent, and checking whether the fix worked. Without that structured handoff, the agent must search raw telemetry to reconstruct the scope and context of the failure before it can investigate. Today, we are introducing **Issues**, [built-in error monitoring for Cloudflare Workers](http://developers.cloudflare.com/workers/observability/issues/) (now in open beta!) to streamline this workflow. Issues can: Fix your first issue with the following prompt for your agent with [CF CLI](https://blog.cloudflare.com/cloudflare-cf-cli-launch/) or checkout the [documentation](https://developers.cloudflare.com/workers/observability/issues/#enable-issues) to get started: ``` Set up cf: https://developers.cloudflare.com/cf/. Enable Issues for this Worker in cloudflare.config.ts; show the diff and ask before deploying. After approved deployment, wait 1 minute, then find the most frequent issue and retrieve an occurrence using its returned ID: cf observability issues list --order-by count --order desc --per-page 1 cf observability issues occurrences <ISSUE_ID> --per-page 1 If no issues exist, report that. Otherwise, diagnose from the details, fix locally, run relevant checks, and show the diff and results. Ask before deploying the fix. ``` [With one line of configuration](http://developers.cloudflare.com/workers/observability/issues/#enable-issues), you can start receiving Issues detected on your Worker with no additional instrumentation required. Issues are built into the Workers runtime, so there is no SDK to install or application wrapper to add. Once enabled, Issues records uncaught exceptions, failed invocations, HTTP `5xx` responses, output from `console.log()` and `console.error()`, and logs that contain a stack trace. It also flags runaway alarm conditions and code that writes large volumes of logs inside loops. Consider a Worker whose handler starts throwing errors after a deployment. Every failed request has a different request ID, but they all come from the same bug. Issues groups them together and shows when the error first appeared, how many times it has happened, and whether it is becoming more frequent. When you open an issue you can see the error, a stack trace when available, the logs and traces leading up to it, the Worker version, request details and trend of the issue over time, as shown below: Cloudflare can capture what happened inside the Worker, but it does not know which users, accounts, or sessions matter to your application. Use the [Worker runtime's](https://github.com/cloudflare/workerd) built-in [OpenTelemetry API](https://opentelemetry.io/) to [add those identifiers](https://developers.cloudflare.com/workers/observability/traces/custom-spans/), without installing another package: Those identifiers appear with each occurrence. In this issue, you can now see whether failures are concentrated in one account or session before sending the issue to an agent. An issue no longer has to sit in a dashboard while someone copies a stack trace and pastes it into a prompt. Configure an automation once, and when an issue crosses an occurrence threshold or returns after a quiet period, Issues sends it straight to your agent through [**Automations**](http://developers.cloudflare.com/workers/observability/issues/automations/). You can choose when the automation should run and where the issue should go. This can be via: When the automation runs, Issues sends the failure summary and diagnostic context captured with the issue — the exception, error, source-mapped stack trace, leading and trailing logs and traces, Worker version, and the application context you added. For deeper investigation, you can connect the agent separately to [Cloudflare MCP](https://github.com/cloudflare/mcp-server-cloudflare/tree/main/apps/workers-observability) that lets the agent query the related logs and traces so that it can propose code and test changes and open a pull request. You stay in control of what reaches production: review the pull request, deploy the fix, and mark the issue resolved. [Cloudflare Workflows](https://developers.cloudflare.com/workflows/), a primitive that powers long-running, multi-step applications, is built entirely on the Workers platform. Behind the scenes, its services keep track of steps, retries, and saved state. This makes Workflows a useful place to test Issues on our own production systems. Within a day of turning it on, the team found two unusual problems hidden inside a large volume of traffic. Instead of leaving the team to connect thousands of separate pieces of telemetry and user reports, their automation setup sent these issues directly to [Cloudflare OS](https://blog.cloudflare.com/cloudflare-os/), which followed the errors into the Workflows code and proposed a fix for both issues. Ready to see what Issues finds in your app? To get started: `observability.issues.enabled` to `true` in your `wrangler.jsonc` file If your agent is handling setup, it can also use the new [cf CLI](https://blog.cloudflare.com/cloudflare-cf-cli-launch/) to inspect issues and create automations. Check out our [documentation](http://developers.cloudflare.com/workers/observability/issues/automations/) to learn more!