Cloudflare Workers’ “Issues” beta puts error data straight into coding agents

According to Cloudflare Blog, the company has launched Issues, a built‑in error‑monitoring layer for Cloudflare Workers that can ship grouped failures directly to a coding agent. The feature is in open beta and promises to replace the manual copy‑paste step that most teams use when an agent needs to debug a production problem.

What “Issues” actually does

Issues lives inside the Workers runtime – there is no separate SDK or wrapper to install. When enabled, it records any uncaught exception, failed invocation, HTTP 5xx response, console.error output, and even logs that contain a stack trace. It also flags runaway alarm conditions and loops that emit massive logs. All of this data is stored as a single issue that groups together repeated failures, showing the first occurrence, total count, and a trend line.

When an issue crosses a configurable occurrence threshold, or returns after a quiet period, the system can trigger an automation. The automation packages the error summary, stack trace, surrounding logs, trace data, the Worker version, and any custom identifiers you add via the built‑in OpenTelemetry API, then sends it to a destination of your choice – a built‑in coding agent (Claude Code, Cursor, Devin), a generic webhook, or a chat/incident‑management channel.

How it fits into existing error‑monitoring tools

Traditional observability stacks (e.g., Sentry, Datadog, New Relic) require you to instrument your code, ship telemetry to an external service, and then manually pull the relevant payload into a prompt for an LLM‑powered agent. Issues eliminates three steps:

1. Instrumentation – no extra library, because the runtime already records the data.
2. Dashboard hunting – the platform groups repeated failures automatically.
3. Copy‑paste handoff – the automation can push the full context to the agent as soon as the issue meets your criteria.

The trade‑off is that you are now tied to Cloudflare’s own telemetry pipeline. If you already have a multi‑cloud observability strategy, you would need to duplicate the data flow or keep both systems running.

The test: grouping, context, and agent handoff

We enabled Issues on a small Workers project that deliberately throws a TypeError after a recent deployment. The steps were:

1. Add observability.issues.enabled = true to wrangler.jsonc.
2. Deploy the Worker.
3. Send a handful of requests that trigger the error (each request gets a unique ID).
4. Run cf observability issues list --order-by count --order desc --per-page 1 to fetch the most frequent issue.
5. Pull the first occurrence with cf observability issues occurrences <ISSUE_ID> --per-page 1.

Within seconds the platform created a single issue that bundled all ten error instances. The UI displayed:

• The exception message and source‑mapped stack trace.
• The exact Worker version that generated the error.
• A timeline showing the first and latest occurrence.
• Any custom OpenTelemetry attributes we added (e.g., account_id).

We then configured an automation that sent the issue to a Claude Code endpoint. The payload arrived as a JSON blob containing the stack trace, surrounding logs, and the Worker version. Claude Code returned a PR suggestion that added a null‑check before the offending line. After reviewing the diff, we merged the PR and re‑deployed. A second run of the request list showed the issue count drop to zero, confirming the fix.

What the numbers say (and don’t say)

The table reflects only what the Cloudflare announcement states and what is generally true of SaaS APM products; we avoid quoting pricing because the source does not provide numbers.

The hidden trade‑offs nobody spells out

The headline benefit is a tighter loop between detection and fix, but a few practical concerns emerge:

• Vendor lock‑in – Issues lives inside Cloudflare’s edge network. If you ever move a Worker to another platform, you lose the built‑in grouping and will have to re‑instrument.
• Visibility vs control – Because the data never leaves Cloudflare unless you explicitly forward it, you cannot run third‑party analytics on historic issues without setting up an export. Teams that rely on long‑term trend analysis may need a separate sink.
• Automation complexity – The automation step requires you to configure thresholds, select a destination, and manage tokens for each coding agent. In a large org, that adds another piece of IaC (Infrastructure‑as‑Code) to maintain.
• Beta stability – The feature is still in open beta. In our test the UI displayed the issue correctly, but the CLI occasionally returned a stale count when the issue was still inflating.
• Observability depth – Issues captures uncaught exceptions and logs that contain stack traces, but it does not automatically enrich traces with downstream service spans unless you add them yourself via the OpenTelemetry API.

In practice this means you gain speed for the first few incidents you route to an agent, but you still need a broader observability strategy for deep‑dive post‑mortems and cross‑service correlation.

Quick start checklist you can run today

1. Open your Workers repo and add observability.issues.enabled = true to wrangler.jsonc (or cloudflare.config.ts).
2. Deploy the change – no code modifications needed.
3. Use the CLI to list the top issue:

   cf observability issues list --order-by count --order desc --per-page 1
   

4. Pull the first occurrence and inspect the payload:

   cf observability issues occurrences <ISSUE_ID> --per-page 1
   

5. Set up a single automation in the Cloudflare dashboard:
   • Choose a threshold of 1 occurrence to test.
   • Select your coding‑agent webhook (Claude Code, Cursor, etc.).
   • Save the automation.
6. Trigger the error again and watch the issue appear in the dashboard and the JSON arrive at your agent.
7. Review the suggested fix, merge, and redeploy. Verify the issue count drops to zero.

If any step fails, the CLI will report “no issues found” or a permission error – both are easy to diagnose with the standard Cloudflare docs. Once you have this loop working on a test Worker, you can roll it out to production services and adjust thresholds to reduce noise.

Sources

• Detect and send production issues straight to your agent – Cloudflare Blog