Agents can already query observability data, navigate a repository, change code, write tests, and open a pull request. The manual step is joining those capabilities together: noticing that repeated failures share a single bug, collecting the logs and traces that describe it, handing that context to an agent, and verifying the fix. Without a structured handoff, the agent has to reconstruct the failure from raw telemetry first.

Issues, Cloudflare's built-in error monitoring for Workers, is now in open beta and targets exactly that gap. It 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, which runs its own workflow — triage, further queries, and eventually a pull request.

Enablement and what gets captured

Detection requires one line of configuration. Because Issues is part of the Workers runtime, there is no SDK to install and no application wrapper to add.

Once on, Issues records uncaught exceptions, failed invocations, HTTP 5xx responses, output from console.log() and console.error(), and any logs carrying a stack trace. It also flags runaway alarm conditions and code that emits large volumes of logs inside loops.

Grouping is the point. A Worker whose handler begins throwing after a deployment produces a failed request with a distinct request ID each time, yet all of them trace to one bug. Issues consolidates them and reports when the error first appeared, its occurrence count, and whether it is trending upward.

Opening an issue exposes the error, a stack trace where one exists, the preceding logs and traces, the Worker version, request details, and the trend over time.

Binding errors to your own identifiers

Cloudflare sees what happens inside the Worker; it does not know which users, accounts, or sessions matter to your application. The Worker runtime ships an OpenTelemetry API, so you can add those identifiers without pulling in another package.

The identifiers are attached to every occurrence, so before dispatching an issue to an agent you can check whether failures cluster around a single account or session.

import { tracing } from "cloudflare:workers";

export default {
  async fetch(request: Request): Promise<Response> {
    const { userId, accountId, sessionId } = await getAuthDetails(request);
    const span = tracing.getActiveSpan();

    span?.setAttribute("user.id", userId);
    span?.setAttribute("account.id", accountId);
    span?.setAttribute("session.id", sessionId);

    return handleRequest(request);
  },
} satisfies ExportedHandler;

Automations: routing issues to an agent

Automations remove the copy-and-paste step. Configure one, and when an issue crosses an occurrence threshold or resurfaces after a quiet period, Issues forwards it to your chosen destination. Both the trigger condition and the destination are configurable, and the destination can be:

  • Built-in coding agents. Claude Code via a routine ID and token, Cursor via an automation webhook URL, or Devin via an API token and organization ID.
  • Generic webhooks. Issue context delivered to your own agent or any HTTPS endpoint.
  • Chat and incident management. Notify the team through chat or an on-call workflow.

Each automation run carries the failure summary and diagnostic context: the exception or error, a source-mapped stack trace, leading and trailing logs and traces, the Worker version, and the application context you added. For investigation beyond the payload, the agent can be connected to Cloudflare MCP to query related logs and traces, propose code and test changes, and open a pull request. The review, deploy, and resolution steps stay with you.

Two Workflows bugs found the same day

Cloudflare Workflows — the primitive behind long-running, multi-step applications, built entirely on the Workers platform — tracks steps, retries, and saved state across its services, which made it a good internal test bed for Issues. Within a day of enabling it, the team surfaced two edge cases buried in a large volume of traffic:

  • A migration stuck in a retry loop. A control plane migration repeatedly hit a SQLite foreign key error when applying migrations in an edge case. Issues let the team pinpoint and fix it.
  • A deletion process that never completed. Deleting Workflow instances could, in an edge case, exceed a Workers subrequest limit and fail to finish. Issues again helped identify and resolve the problem.

Rather than asking anyone to stitch together thousands of separate telemetry records and user reports, the team's automation routed both issues to Cloudflare OS, which followed the errors into the Workflows code and proposed fixes.

Getting started

  1. Set observability.issues.enabled to true in your wrangler.jsonc.
  2. Create your first automation in the Cloudflare dashboard, pointing it at an agent, webhook, incident management tool, or chat platform.

Agents doing the setup themselves can use the cf CLI to inspect issues and create automations; a prompt for that path is available for CF CLI users, and the documentation covers the rest.