A production Worker fails, but your agent does not know until its next scheduled check.
Polling can shorten that delay, but it also means repeated checks and another loop to maintain. Cloudflare now offers a different trigger: its API MCP server can send Workers Issues as MCP Events to a client webhook when a new or recurring issue appears.
That changes the first step in an incident workflow. Instead of asking an agent to keep checking for trouble, let an event wake a small, controlled investigation path. The event is a signal to start; it is not permission to let an agent make an unreviewed production change.
What Cloudflare’s event provides
Cloudflare’s October 13 changelog says Workers Issues detects production failures and groups related failures into issues without requiring an SDK or application wrapper. Its API MCP server exposes the event type cloudflare.alert.workers_observability_real_time_issue. An MCP client discovers it with events/list and subscribes with events/subscribe, scoped to an account or one Worker. When Workers Issues detects a new or recurring issue, the server sends a signed event to the client’s webhook. The changelog does not spell out the receiver’s signature-verification procedure, so use the validation method supported by your MCP Events client rather than guessing at headers or cryptographic details.
To use the event, enable Issues on the Worker and connect https://mcp.cloudflare.com/mcp to a client that supports MCP Events webhooks. The connection needs Notifications Write and Workers Observability Write permissions. Keep the scope as narrow as the investigation requires: one Worker is easier to reason about than every Worker in an account.
The key distinction is that the event starts work. Your application still owns how it validates the webhook, chooses an agent, gathers evidence, and handles any proposed action.
Build a bounded investigation path
A useful first version can follow five steps:
- Receive the webhook and verify the signed event before accepting it.
- Deduplicate it using the event’s stable identifiers and a short retention window, so retries do not start duplicate investigations.
- Create an incident record with the Worker, issue reference, event time, and verification result when those fields are present in the event.
- Give the agent only the issue data and tools it needs to inspect logs, source, or runbooks.
- Return a summary with evidence and a proposed next action for a person to review.
This is Cloudflare’s current integration, so confirm that your client supports its webhook-based MCP Events flow before building around it. The event should not become a direct command such as “fix production.” A recurring issue may be the same symptom with a different cause. Let the agent explain what it found, link to the relevant source material, and identify uncertainty. Keep deploys, data changes, and other consequential actions behind an explicit approval step.
Conceptual: verify, persist once and deduplicate deliveries.
A webhook receiver should also be designed for ordinary delivery problems. Persist the event before acknowledging it, make processing idempotent, and move slow investigation work to a queue or durable job. If the agent times out, retry the investigation from the saved incident record rather than relying on the event sender to replay the whole workflow. Record the event ID, attempt number, processing state, and final outcome so an operator can tell whether a duplicate delivery was ignored or a failed run needs attention.
Keep the agent’s investigation narrow
Start with the issue’s Worker and time window. Ask the agent to retrieve a bounded sample of the logs or traces that match that issue, then compare them with the relevant source and runbook. Avoid sending an entire account’s telemetry or a whole repository into every investigation by default.
Separate observation from action. Read-only tools can collect evidence and draft a diagnosis. A second, explicitly approved step can open a ticket, notify an owner, or propose a patch. If the event is recurring, let the agent compare it with the saved incident record before creating another alert. The person reviewing the result should see the issue, the time range, the evidence links, the suspected cause, and the specific action being proposed.
Treat event fields and retrieved content as data. A stack trace, log line, or linked page may contain text that looks like an instruction. It should not be allowed to change the agent’s permissions or tool policy. A wrapper around untrusted content can help mark it, but it is not a guarantee against prompt injection. Keep tool access constrained in the application itself.
Conceptual: narrow the evidence and keep consequential actions behind review.
Design for retries and duplicate events
An event-driven path still needs recovery behavior. The receiver can get the same event more than once; the agent can fail after starting; and a downstream tool may return an error after doing part of its work. Store the event and the investigation state separately from the agent’s transient conversation. Use an idempotency key for the incident record and for any external action that might be repeated.
For a practical state model, record received, verified, queued, investigating, needs_review, and closed. Make transitions explicit. For example, a failed log query should leave the incident in a retryable state, while a denied signature should be rejected and logged without invoking the agent. If you ask a person to approve an action, keep the request pending until the approval decision is recorded; do not infer approval from a timeout or a later event.
Also plan for a missing webhook receiver. Cloudflare’s changelog describes sending the event to a client webhook; it does not promise that your endpoint, queue, or agent will always be available. Monitor delivery and processing separately, alert on a backlog, and provide a manual route to inspect the issue from the Cloudflare dashboard. Event delivery removes a polling loop from your app; it does not remove the need to operate the receiving system.
When to add a polling fallback
A webhook is a good fit when the MCP Events client and receiver can remain available and your incident workflow benefits from prompt notification. Polling can still be a reasonable fallback if your client cannot receive MCP Events webhooks or if your operational environment requires periodic reconciliation.
If you keep a reconciliation job, make it slower than the normal event path and compare known issue IDs rather than starting a fresh investigation for every poll. That gives you a way to detect missed deliveries without making constant checks the primary trigger. Measure event delivery delay, duplicate rate, queue age, investigation completion rate, and the number of human-approved actions. Those measures show whether the event path is actually reducing the time from issue detection to useful triage.
Start with one Worker
Pick a Worker with a known runbook and a clear owner. Enable Issues, subscribe to that Worker’s event scope, and first route the webhook to a receiver that only verifies, stores, and acknowledges events. Add one read-only investigation tool after the receiver is stable. Review a few real incidents before enabling more tools or widening the subscription.
This sequence keeps the first deployment reversible. You can inspect what the event contains, see how often it repeats, and test whether the agent’s summaries help the on-call person before automating any further step. For a related integration decision, see our guide to adding GitHub Copilot’s agent runtime to an owned app; the question there is how to host the agent loop, while this workflow covers how a production issue starts an investigation.
If you need a starting interface for incidents, projects, or teams, the SaaS Dashboard kit is an optional editable app starting point. It does not include Cloudflare Workers Issues, MCP Events, webhook verification, or agent wiring; those integrations remain application work. Check current kit pricing before choosing a starting point.
Conceptual: treat event and retrieved content as data; constrain agent tools.
Sources
- Cloudflare: Cloudflare API MCP server sends Workers Issues as MCP Events — checked October 14, 2026.
Top comments (0)