This tool bridges the gap between production observability and AI-driven remediation. By automating the handoff of error context to coding agents, it reduces the manual effort required to diagnose, fix, and deploy patches for production bugs in serverless environments.
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 (now in open beta!) to streamline this workflow. Issues can:
Fix your first issue with the following prompt for your agent with CF CLI or checkout the documentation to get started:
With one line of configuration, 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 built-in OpenTelemetry API to add those identifiers, 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. 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 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, 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, 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 fileIf your agent is handling setup, it can also use the new cf CLI to inspect issues and create automations. Check out our documentation to learn more!
Continue reading on the original blog to support the author
Read full articleAI agents require immediate, isolated, and stateful Linux environments. By making container provisioning programmable at runtime and slashing startup times to sub-second levels, Cloudflare enables developers to build highly responsive, scalable agentic workflows without infra overhead.
As AI agents increasingly manage infrastructure, traditional human-centric CLIs become bottlenecks. Cloudflare's 'cf' CLI solves this by providing agent-optimized JSON outputs, full API coverage via automated generation, and TypeScript-based configuration for better safety and discovery.
As AI agents now drive nearly 50% of CLI usage, 'cf' optimizes for this shift by providing 3,000+ API operations, JSON-first output, and TypeScript configs. This enables engineers to leverage agents for full-stack infrastructure automation with better type safety and discovery.
Moving MCP to a stateless model drastically reduces the complexity and cost of deploying AI agents. Engineers can now build and scale agentic tools using standard serverless infrastructure without managing persistent connections or complex session routing.