Cloudflare Issues Real-Time Error Detection That Feeds Your AI Agent

The Manual Glue Is the Problem

Coding agents can already query observability data, navigate a repo, patch code, write tests, and open a PR. What they can't do is notice that 400 failures with different request IDs all stem from the same bug, then assemble the logs, traces, and Worker version into a coherent context window. That handoff is still a human copying a stack trace into a chat box.

Cloudflare is closing that gap with Issues — built-in error monitoring for Workers, now in open beta. It groups repeated exceptions, 5xx responses, and error logs into a single issue, then pushes that context straight to a configured agent. The result: fewer manual steps between "something broke" and "here's a pull request."

For a broader look at why agentic workflows are becoming table stakes for enterprise teams, see our analysis on how AI agents are redefining enterprise integration.

Enabling Issues in One Line

No SDK, no wrapper, no instrumentation package. Issues are baked into the Workers runtime. Add this to your wrangler.jsonc:

{
  "observability": {
    "issues": {
      "enabled": true
    }
  }
}

Once enabled, the runtime captures:

• Uncaught exceptions and failed invocations
• HTTP 5xx responses
• Output from console.log() and console.error()
• Logs containing a stack trace
• Runaway alarm conditions and log-spam loops

Repeated failures from the same root cause are collapsed into a single issue with first-seen timestamp, occurrence count, and a frequency trend.

Adding Application Context with OpenTelemetry

Cloudflare knows what happened inside the Worker, but not who it happened to. Use the built-in OpenTelemetry API — no extra package — to attach user, account, and session identifiers:

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;

Those attributes ride along with every occurrence, so when an issue fires you can see whether failures cluster in one account or session before deciding to escalate.

Wiring Issues to Your Agent

Issues doesn't just sit in a dashboard. Through Automations, you define a trigger (occurrence threshold, or issue returning after a quiet period) and a destination:

The payload includes the exception, source-mapped stack trace, leading and trailing logs and traces, Worker version, and any custom attributes you added. For deeper investigation, connect the agent to Cloudflare MCP so it can query related logs and traces directly.

Real-World Validation

Cloudflare ran Issues against their own Workflows service (long-running, multi-step apps built on Workers). Within one day of enabling it, they caught two edge-case bugs hidden in high traffic volume: a migration stuck in a SQLite foreign-key retry loop, and a deletion process that exceeded the Workers subrequest limit and never completed. Both were auto-routed to an agent that traced the errors into the Workflows code and proposed fixes.

Caveats Worth Knowing

• Open beta means the API surface and automation config may shift. Don't build critical alerting solely on Issues yet.
• Grouping heuristics aren't perfect. Distinct bugs with similar stack traces can merge; genuinely different root causes with identical exceptions may not split cleanly.
• Agent output still needs review. The PR the agent opens is a starting point, not a merge button. Human review of the fix and deployment remains your responsibility.
• Context is only as good as what you attach. Without OpenTelemetry attributes, the agent sees the failure but not the blast radius.

If you're also weighing broader industry signals around AI tooling, our piece on notable tech April Fools pranks and their fallout is a useful reminder that hype and substance don't always align.

Next Steps

1. Flip observability.issues.enabled to true in your wrangler.jsonc.
2. Add OpenTelemetry attributes for the identifiers your team actually uses in triage (user, account, tenant, session).
3. Configure one Automation to a non-production agent first — watch what it proposes before pointing it at prod.
4. Use the cf CLI to inspect issues and script automation creation if you're managing many Workers.

Where to go deeper: study the OpenTelemetry tracing API for Workers, read up on Cloudflare MCP for agent-side querying, and experiment with source maps so stack traces resolve to your TypeScript, not bundled output. The real win isn't detection — it's the structured handoff from failure to fix. That's the piece most teams are still doing by hand.