Cloudflare Alerts Now Reach Your Coding Agent

Executive Summary

• What's new: since October 2, Cloudflare alerts can be delivered to coding agents, next to email, webhooks and PagerDuty. Webhooks are now on every plan, Free included.
• Workers Issues: built-in error monitoring for Workers, in open beta and free during the beta. Exceptions, failed invocations, 5xx responses and logged errors are grouped into issues, with no SDK.
• The handoff: an automation fires when an issue crosses an occurrence threshold or comes back after a quiet period, and sends the context to Claude Code, Cursor, Devin or any webhook.
• What the agent gets: the exception, a source-mapped stack trace, logs and traces around the failure, the Worker version and any context you added (Cloudflare blog).
• You stay in charge: the agent proposes code and test changes. You review, deploy and mark the issue resolved.

I made a short video of this on X. The error and the agent's steps in it are an illustration of the flow.

Your coding agent now gets Cloudflare's production alerts

One alert hub, more destinations

Cloudflare's Alerts (Observability > Alerts) has two kinds of alerts (docs):

• Platform Notifications: pre-built alerts for DDoS Protection, SSL/TLS, Health Checks, Load Balancing, Billing and more.
• Monitors (beta): your own SQL API query on a schedule, with a threshold, anomaly detection or an SLO target. Anomaly detection is the one for "traffic suddenly spiked".

Every alert can go to:

• Email: all plans
• Webhooks: all plans, up to 100 without a paid zone. Slack and Google Chat connect this way (configure webhooks).
• PagerDuty: Business and higher
• Connected services, including coding agents

DDoS, spikes and errors go where you choose

Workers Issues: errors grouped, then handed off

Issues is built into the Workers runtime. Turn it on in your Wrangler config (Wrangler 4.134.0 or later) and deploy:

[observability.issues]
enabled = true

Keep it in the config: if you deploy with Wrangler and the setting is missing, the next deploy turns Issues off. It only sees traffic after you enable it, and source maps make the stack traces point at your real files.

A caught error is invisible unless you log it. Pass it to console.error() before you return the fallback:

try {
  return await handle(request, env);
} catch (err) {
  console.error(err); // recorded as an occurrence
  return new Response("Something went wrong", { status: 500 });
}

Automations: when the agent gets called

In the dashboard: Issues > Automations > Add automation. Pick one trigger:

• Occurrence threshold: runs once when an issue's count crosses your number, not on every later occurrence.
• Recurrence after inactivity: runs when a known issue comes back after a quiet period, from 1 hour to 365 days.

Then pick the destination. The fields per agent (docs):

• Claude Code: routine ID and authorization token
• Cursor: automation webhook URL, optional authorization header
• Devin: authorization token and organization ID, optional repositories and playbook ID
• Generic webhook: any HTTPS endpoint, secured with a webhook secret or mTLS. Use it for your own agent or an internal workflow.

Cloudflare tries a handoff up to three times before it marks the run failed. You can have 50 automations per account, and run history is kept for 30 days. You can also send a single issue to a destination by hand from the issue page.

Past the threshold, the agent gets the context

Setting up the Claude Code side

Claude Code receives the issue through a cloud scheduled task (formerly "routine") with an API trigger (Claude Code docs):

1. Create a task at claude.ai/code/routines and select the repository of your Worker.
2. Add an API trigger, copy the Fire URL and generate a token. The token is shown once, so paste it straight into Cloudflare.
3. Put the routine ID and token into the Claude Code destination in Cloudflare.

One detail that matters: whatever Cloudflare sends arrives wrapped in a <routine-fire-payload> block that is marked as untrusted data. Your task's prompt has to opt in to acting on it, for example:

Investigate the Cloudflare Workers issue described in the routine-fire-payload
block. Find the failing code in this repository, write a failing test, then
propose the smallest fix and open a pull request. Do not deploy.

That wrapper is a good default. Error messages can carry user input, so an agent that blindly follows text from a stack trace would be a new attack surface.

Two things I'd do before turning it on

• Give the agent read access to logs, separately. An automation does not let the agent query your Cloudflare account. If you want it to dig into logs and traces, connect the Cloudflare API MCP server on purpose, with a read-only token.
• Keep secrets out of telemetry. Issue data can include error messages, stack traces, request metadata and logs, and all of it goes to the agent. Treat destination URLs, webhook secrets and tokens as credentials.

Set it up: turn on Issues, add an automation, pick the agent, add Cloudflare MCP

Sources

• Changelog: Webhooks on all plans and coding agent destinations, October 2, 2026
• Changelog: Monitors (Beta), October 2, 2026
• Cloudflare Alerts docs
• Configure webhooks
• Workers Issues docs
• Issues automations docs
• Detect and send production issues straight to your agent, Cloudflare blog, September 30, 2026
• Claude Code scheduled tasks and API triggers
• @Cloudflare on X