Build a Workers Issues triage prototype with Cloudflare MCP Events

Start with one Worker and an investigation boundary

Cloudflare announced signed webhook delivery for new and recurring Workers Issues through its API Model Context Protocol (MCP) server on October 13, 2026. Cloudflare identifies its first event as cloudflare.alert.workers_observability_real_time_issue. The announcement says clients discover it through events/list and subscribe through events/subscribe. According to Cloudflare, subscriptions can cover an account or an individual Worker. Use that event as the starting point for a prototype that receives an issue, gathers evidence and prepares an investigation report. Sources: Cloudflare

Start with one test Worker and keep deployment authority outside the agent’s tools. Cloudflare says setup requires Issues enabled, a webhook-capable MCP Events client, and Notifications Write plus Workers Observability Write permissions. Configure investigative access separately: Cloudflare’s automation documentation says receiving a notification does not itself grant access to query account telemetry. Make the initial deliverable a report with observed symptoms, evidence links, hypotheses, uncertainty and suggested next steps. Keep proposed changes subject to human review. Sources: Cloudflare

Enable Issues and capture the subscription contract

Enable Issues in the Worker’s deployment configuration before generating failures. Cloudflare documents the following configuration for Wrangler 4.134.0 or later. Dashboard enablement must also appear in Wrangler configuration, or the next deployment disables Issues. Detection covers traffic after enablement rather than historical failures. Sources: Cloudflare

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

Cloudflare groups related occurrences within a Worker into an issue, drawing on uncaught exceptions, failed invocations, 5xx responses and logged errors. Generate a controlled failure, then save discovery schemas and the subscription response with the test record. The February 19, 2026, event design sketch is a draft describing advertised delivery modes, subscription-input schemas and payload schemas. It describes a subscription ID and refreshBefore value, with renewal governed by the expiration the server grants. Replay depends on upstream support, and the draft excludes replay before subscription time from its initial scope. Record the draft revision and schedule renewal from the actual response. Sources: Cloudflare, Model Context Protocol

Authenticate delivery before accepting work

Build the receiver separately from the agent so authentication and persistence can be tested without model behavior. OpenAI’s MCP Events documentation specifies webhook-id, webhook-timestamp and webhook-signature headers, plus X-MCP-Subscription-Id. Its signatures cover the event ID, signing timestamp and exact body bytes; callback verification uses a signed challenge. Treat this documentation as an implementation reference when evaluating a compatible client. Preserve the received bytes and verify authenticity and timestamp before validating the envelope and permitted account and Worker scope. Sources: OpenAI

A Nerd Level Tech tutorial reported that re-serializing a simulated Unicode-escaped JSON body changed its bytes and broke signature verification. The author also found that shared subscription secrets let an unsigned subscription-header change bypass the example’s deduplication boundary. Use separate secrets for subscriptions and bind routing to the expected secret and authorized scope. Prepare verification state before subscribing: the tutorial reports that the callback challenge can arrive before the subscription response supplies its ID. A valid signature establishes message authenticity, not the correctness of an agent’s diagnosis. Sources: Nerd Level Tech

Persist deliveries and distinguish incident episodes

After verification, atomically persist the accepted delivery and pending triage work in a durable inbox. Acknowledge receipt after persistence succeeds, then let a separate worker collect evidence. OpenAI’s implementation treats a 2xx response as acknowledgment before asynchronous processing. Its retries preserve the event ID but receive fresh signing timestamps and signatures. Recording an event as seen before scheduling work creates a loss window; scheduling first creates a duplication window. Persist deduplication state and pending work together so both survive restarts. Sources: OpenAI

Keep transport identity separate from incident identity, using the proposed mapping in the table below. The tutorial reported that global event-ID deduplication discarded an intended delivery when two subscriptions received the same event ID. Cloudflare’s automation documentation defines recurrence as an existing issue returning after a configured quiet period, with an earlier occurrence required. Its occurrence-threshold trigger runs once when an issue crosses the configured count, rather than for every later occurrence. Correlate the continuing issue without letting its identity suppress future episodes. Select payload fields only after inspecting discovery responses and deliveries. Sources: Nerd Level Tech, Cloudflare

Exercise failures before connecting remediation tools

Run the proposed acceptance tests below before connecting remediation tools. Start with authentic fixtures and callback verification, then vary bytes, routing and timestamps independently. Include concurrent deliveries and process termination to expose persistence races. Record each observation as a test result, keeping expected behavior separate from measured behavior.

Test recurrence with synthetic receiver fixtures, then repeat a real failure after the configured quiet interval. Synthetic fixtures exercise application logic; the live experiment checks provider grouping and trigger behavior. Record provider handoff, webhook receipt, durable acceptance and completed triage separately. Cloudflare says a successful automation run means Notifications accepted the handoff, which Cloudflare attempts up to three times. Treat that status as a handoff milestone rather than proof of completed triage. Include hostile instructions in exception messages and logs, and require the agent to treat them as evidence rather than authority. Sources: Cloudflare

Measure the whole path before expanding authority

Compare the event subscriber with a fixed-interval poller using identical Workers, generated failures, evidence queries, model versions and prompts. Record failure time, issue visibility, webhook arrival, durable acceptance, triage start and report completion. Separate detection, transport, queue and inference delays. Report latency percentiles alongside missing events, duplicates, retries and model and tool costs. Publish sample size, geography, clock synchronization, polling interval, concurrency, payload sizes and retry policy. Include idle periods, bursts, outages and recurrence to capture operational trade-offs.

The research included no deployed Cloudflare test or controlled benchmark of end-to-end latency, loss or remediation quality. Cloudflare-specific retries, payload limits, replay, recurrence identifiers and the mapping between subscriptions and automation triggers remain unresolved. OpenAI documents out-of-order arrival and a 256 KiB body ceiling for its implementation; those details do not establish Cloudflare’s contract. Resolve delivery questions through captured responses and experiments, then assess triage against a labeled incident set. Before expanding authority, require passing delivery, recovery and recurrence tests, plus evidence-backed triage. Introduce actions through a narrow allowlist with fresh state checks, action idempotency, rollback criteria and an audit trail. Sources: OpenAI