Workers Issues: route Cloudflare errors to coding agents

Cloudflare launched Issues on 30 September 2026. It is error monitoring built into the Workers runtime, and it is in open beta. Once you turn it on, every failure your Worker produces is recorded as an occurrence, and occurrences from the same bug are grouped into one issue. An automation then sends that issue, with its stack trace, logs, traces and Worker version, to a coding agent, a webhook, a chat channel or an incident tool. It fires when the issue crosses an occurrence threshold, or when it comes back after a quiet period.

This guide covers what Issues records, how it changes the way errors reach your agent, how to turn it on today, and the beta limits and gotchas stated in Cloudflare’s announcement and docs. Issues is free for every Workers account during the beta.

What Cloudflare Workers Issues is

Issues is a detection and grouping layer that sits inside the Workers runtime. There is no SDK to install and no wrapper around your handler. You change one line of configuration and deploy. Cloudflare records each failure as an occurrence, then groups related occurrences from the same Worker into an issue. Every failed request has its own request ID, but if the failures share a cause they become one issue. The issue shows when the error first appeared, how many times it has happened, and whether it is getting more frequent.

An issue has one of three statuses:

• Active: unresolved. Every new issue starts here.
• Resolved: you consider it fixed. A newer occurrence moves it back to Active.
• Ignored: it stays ignored when new occurrences arrive, until you change it.

What Issues counts as a failure

According to the Investigate issues docs, Issues detects:

• uncaught exceptions
• failed invocations
• HTTP 5xx responses returned by the Worker
• console logs written at error level, or that contain an Error object or a stack trace

The announcement adds that Issues flags runaway alarm conditions and code that writes large volumes of logs inside loops. Detection works without Workers Logs or tracing. You only need tracing to attach your own application context, which is covered below.

How Issues changes the path from a failing Worker to your agent

Coding agents can already query telemetry, read a repository, write a fix and open a pull request. Cloudflare’s announcement points at the manual part in between. Someone has to notice that a hundred failed requests share one bug, collect the logs and traces, paste them into an agent and check later whether the fix worked. Without a structured handoff, the agent has to search raw telemetry to work out the scope of the failure before it can start.

Issues takes over three of those steps:

1. Grouping. Repeated exceptions, 5xx responses and error logs become one issue with a count and a trend.
2. Packaging. Each occurrence carries the error, a source-mapped stack trace when available, the logs and traces before and after it, the Worker version, invocation and request details, and any attributes you set on the active span.
3. Handoff. An automation sends that package to the destination you choose, once, when its trigger condition is met.

The fourth step stays with you. Cloudflare’s docs say the agent can propose code and test changes, and you review and deploy them, then mark the issue resolved. Issues never closes anything automatically.

Cloudflare tested this on Workflows, which runs on the Workers platform. Within a day of turning Issues on, the Workflows team found two bugs hidden in a large volume of traffic: a control plane migration stuck retrying on a SQLite foreign key error, and an instance deletion that could exceed a Workers subrequest limit and never finish. Their automation sent both issues to an agent, which proposed fixes.

Turning on Issues for a Worker

You can enable Issues three ways. Pick the one that matches how you deploy, because the deploy tool’s config wins.

With Wrangler

You need Wrangler 4.134.0 or later.

1. Check your version:

npx wrangler --version

2. Set observability.issues.enabled in your Wrangler config:

// wrangler.jsonc
{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "observability": {
    "issues": {
      "enabled": true
    }
  }
}

Or in TOML:

[observability.issues]
enabled = true

3. Deploy:

npx wrangler deploy

From the dashboard

Open the Worker’s Issues page and select Enable issues. If you deploy with Wrangler, also set the flag in your config file. Otherwise your next wrangler deploy turns Issues off again.

With the cf CLI

cf is Cloudflare’s new CLI for the public API and Workers projects, and it is also in beta. Projects use a typed cloudflare.config.ts:

// cloudflare.config.ts
import { defineConfig } from "cf/config";
import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };

export default defineConfig({
  worker: {
    name: "example-worker",
    entrypoint,
    compatibilityDate: "2026-09-30",
    observability: {
      issues: {
        enabled: true,
      },
    },
  },
});

npm install --global cf
cf deploy

If the project is still configured for Wrangler, run cf migrate before cf deploy. You can run cf resource commands next to a Wrangler project without migrating it.

Issues only processes traffic that arrives after you turn it on. It does not scan past failures. Send production traffic, then open the Issues page.

Recording handled errors and adding user and account context

Report errors your code catches

An error you catch and turn into a fallback response is invisible to Issues unless you log it. Pass the caught value to console.error() before you return:

try {
  return await handleRequest(request);
} catch (error) {
  console.error(error);
  return new Response("Service unavailable", { status: 503 });
}

Attach the identifiers your agent needs

Cloudflare captures platform context, but it can’t know which user, account or session matters to your app. Turn on tracing for the Worker, then set attributes on the active span as early in the invocation as you can, using the runtime’s built-in OpenTelemetry API:

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;

These attributes appear with each occurrence, so you can see whether failures cluster in one account before you hand the issue off. Having built and led the Workers observability team at Cloudflare, I’d set them on day one: an agent given an account ID can tell a single bad tenant from a broken release. Never put secrets, access tokens or sensitive request content in span attributes, logs or error messages. All of it travels to whatever destination you configure.

Reading an issue from the dashboard or the cf CLI

In the dashboard, the Issues overview lists active and resolved issues with occurrence totals. Open an issue to see when it started, how often it happened and its status. Then select an occurrence for the error, the stack trace, the related logs and traces, the Worker version, request details and your span attributes. What you see depends on the failure type and the telemetry captured for that invocation.

From a terminal, or from an agent that runs cf, the announcement gives two commands. The first lists the most frequent issue. The second fetches one occurrence by the ID it returns:

cf observability issues list --order-by count --order desc --per-page 1
cf observability issues occurrences <ISSUE_ID> --per-page 1

Cloudflare’s suggested first prompt asks the agent to enable Issues in cloudflare.config.ts, show the diff and ask before deploying. After the deploy it waits a minute and runs those two commands. If there are issues, it diagnoses one, fixes it locally, runs checks and asks again before deploying the fix.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> enable Issues on this Worker, then diagnose the most frequent issue and show me the diff

? for shortcuts

Sending issues to Claude Code, Cursor, Devin or a webhook

An automation pairs a trigger with a destination. You set it up in the dashboard or with cf.

Choosing a trigger

• Occurrence threshold: runs once when an issue’s occurrence count crosses the value you set. It does not run again for each occurrence after that. The minimum threshold is 1.
• Recurrence after inactivity: runs when an existing issue comes back after a set period with no newer occurrence. The period can be anywhere from 1 hour to 365 days, and the issue needs at least one earlier occurrence.

A threshold catches new bugs that matter. A recurrence trigger catches regressions of bugs you thought were fixed.

Creating the automation

1. Open the Worker’s Issues page.
2. Select Automations, then Add automation.
3. Pick an occurrence threshold or recurrence trigger and enter its value.
4. Pick an existing destination or create one.
5. Turn on Enabled and select Create.

What each coding agent destination needs

Every coding agent destination needs a display name. Beyond that:

• Claude Code: a routine ID and an authorisation token, from a routine with an API trigger.
• Cursor: an automation webhook URL, with an optional authorisation header.
• Devin: an authorisation token and an organisation ID, with optional repositories and a playbook ID.

The agent receives the issue summary and the captured context: exception, source-mapped stack trace, leading and trailing logs and traces, Worker version and your application context. What it does next is set by the agent’s own configuration, which can range from triage to opening a pull request.

The other destination types are Chat, which posts a summary to a team channel, and Incident management, which creates an incident or notifies an on-call workflow.

Building your own receiver with a generic webhook

To use your own agent or an internal workflow, create a Generic Webhook destination. Give it a name and an HTTPS URL, then either enter a webhook secret or turn on mutual TLS. Generic webhooks use the standard Cloudflare Notifications payload. That means:

• Your secret arrives in the cf-webhook-auth header. Reject any request where it is missing or wrong.
• Requests come from Cloudflare’s published IP ranges, so allowlist them if a firewall sits in front of the endpoint.
• Delivery only goes to a publicly resolvable address on port 80 or 443. For a private endpoint, put a Worker or a Cloudflare Tunnel in front of it.

A minimal receiver written as a Worker:

interface Env {
  WEBHOOK_SECRET: string;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    if (request.headers.get("cf-webhook-auth") !== env.WEBHOOK_SECRET) {
      return new Response("unauthorised", { status: 401 });
    }
    const event = await request.json();
    // Store the event, then hand it to your agent or a queue.
    console.log(JSON.stringify(event));
    return new Response("ok");
  },
} satisfies ExportedHandler<Env>;

Cloudflare’s Notifications webhook page says webhooks need an account with at least one zone on a Pro plan or above. The Issues docs don’t repeat that requirement, so check it in your account before you build on generic webhooks.

Testing without waiting for a trigger

Open any issue and pick a destination from its actions to send it straight away. The manual run shows up in the issue’s activity history. Each run is pending, succeeded or failed. Cloudflare tries the handoff up to three times before marking it failed. A succeeded run means Cloudflare Notifications accepted the event for delivery, which does not prove your agent acted on it.

Giving the agent read access to logs and traces

An automation sends an issue. It does not give the destination any permission to query your Cloudflare account. If you want the agent to pull more logs and traces than the issue carries, configure the Workers Observability MCP server for it separately. Grant only the access the investigation needs, and treat destination URLs, webhook secrets and access tokens as credentials.

Before you pick a destination, review its access controls and data handling. Issue data can include error messages, stack traces, request metadata, logs and the identifiers you attached.

Beta limits and retention to plan around

Workers Issues limits and retention during the open beta

Item	Value
Price during open beta	Free for all Workers accounts
Automations per account	50
Minimum occurrence threshold	1
Recurrence inactivity period	1 hour to 365 days
Completed automation-run history	30 days
Occurrence detail retention	7 days
Handoff attempts per automation run	Up to 3
Minimum Wrangler version	4.134.0

Issues stay listed after their occurrences expire, but the stack traces and logs are gone after seven days. If your agent or your team works an issue later than that, the evidence has to come from somewhere else.

The 50-automation cap is per account. One automation per Worker per trigger type uses it up fast on a large account, so plan shared destinations early.

Where teams trip up with Workers Issues

• Issues switches itself off after a deploy. You enabled it in the dashboard and deployed with Wrangler. Fix: put observability.issues.enabled in the Wrangler config, or worker.observability.issues.enabled in cloudflare.config.ts.
• Your Wrangler version is too old. Issues needs Wrangler 4.134.0 or later, and older versions are not supported. Fix: upgrade Wrangler.
• The page is empty. Issues ignores failures from before you enabled it. Fix: send traffic, or wait for real production traffic, then check again.
• Caught errors never show up. Your handler swallows them and returns a fallback. Fix: call console.error(error) in the catch block.
• Span attributes are missing. Tracing is off. Fix: turn on tracing for the Worker before using tracing.getActiveSpan().
• The agent only gets one ping for a busy issue. That is how the threshold trigger behaves. Fix: add a recurrence-after-inactivity automation for regressions.
• Issues pile up as Active forever. Nothing resolves on its own. Fix: mark issues Resolved after the fix ships. A new occurrence moves the issue back to Active, which is your regression signal. A delayed occurrence recorded before you resolved it does not reopen it.
• The agent can’t find more context. The automation carries no account access. Fix: connect the Workers Observability MCP server to the agent.
• The run says succeeded but nothing happened. Succeeded only means Notifications accepted the event. Fix: log what your receiver gets, and check the agent’s own run history.
• Secrets leak into an agent’s context. A token ended up in a log line or span attribute. Fix: scrub it at the source, because every destination sees what Issues captured.
• cf deploy fails in a Wrangler project. Fix: run cf migrate first, or keep deploying with Wrangler.

A rollout order for your first Worker

1. Upgrade Wrangler to 4.134.0 or later, set the Issues flag in config and deploy.
2. Add console.error() to the catch blocks that return fallbacks.
3. Turn on tracing and set user, account and session IDs on the active span.
4. Let a day of traffic arrive, then read the top issues yourself before you automate anything.
5. Create one occurrence-threshold automation to a coding agent, and test it with a manual run.
6. Connect the Workers Observability MCP server if the agent needs to query beyond the issue.
7. Add a recurrence automation for regressions, and a chat or incident destination for anything people must see.
8. Review every proposed change, deploy it yourself and mark the issue Resolved.

To turn Issues off, set the flag to false and deploy. Issues stops detecting new failures.

Taking Workers issues from alert to pull request with Polylane

Polylane connects a Cloudflare account with a read-only token and triages its alerts automatically. Each real problem becomes one issue worked by a single fix run, which reaches a verdict, traces the cause with cited evidence and opens the fix as a pull request you review. It also flags Workers whose logs are disabled as an advisory, so the telemetry an investigation depends on is in place before something breaks.

Running on Cloudflare? See how Polylane monitors Cloudflare in production.