Cloudflare Observability MCP: Prove a Zero-Log Result

An empty response from the Cloudflare Observability MCP server is not evidence that a Worker is healthy. It is evidence that one query returned no rows. Before turning that into a verdict, prove that the query used the intended Cloudflare account, Worker, time window, log configuration, and field set—and that the same scope can retrieve a known control invocation. The reasonable default is strict: call a filtered zero row result healthy empty only when Workers Logs and invocation logs are enabled, the head sampling rate is 1 , the window is inside retention, field discovery succeeds, the query completes, and a broader query finds a known invocation in the same account, Worker, and window. If any receipt is missing, keep the state unknown or route the specific configuration failure. This matters because the remote MCP exchange can succeed while the evidence layer is incomplete. The protocol result answers “did the tool return?” The operator still has to answer “did this query cover the events needed for this decision?” A successful MCP query can still be an evidence failure Cloudflare lists a managed Observability server for debugging application logs and analytics. The current Cloudflare MCP server catalog provides its remote endpoint, says new connections use Streamable HTTP, and explains that authorization is handled through Cloudflare OAuth. The Workers Observability MCP repository documents three tools: query worker observability queries Workers logs and metrics; observability keys discovers metadata, Worker specific fields, and custom fields; observability values finds available values for a selected field. Those tools are enough to investigate many incidents, but their success envelopes do not prove coverage. The repository also says each request gets fresh, request scoped authorization and account context. Therefore, do not assume that because the previous request used the right account, the next request necessarily did. Record a non secret account reference and Worker reference with every query receipt. There are several ways to obtain a convincing looking empty result: 1. OAuth completed, but the selected account is not the production account. 2. The Worker name or environment filter resolves to nothing. 3. Workers Logs is disabled for that deployment. 4. Invocation logs are explicitly disabled. 5. Head sampling omitted the invocation you expected to find. 6. The requested window is older than retained data. 7. The filter uses a field or value that is absent from the current schema. 8. The filtered result is genuinely empty. Only the last state supports “no matching incident,” and even then only for the bounded scope and window. Collapsing the list into success discards the exact evidence an operator needs. Prove the dataset before interpreting the filter Start from collection, not from the incident query. Cloudflare's current Workers Logs documentation says a Worker must have observability enabled to write to Workers Logs. It also documents a separate invocation logs = false setting. A Worker can therefore run successfully while the invocation evidence your audit expects is deliberately absent. Sampling is another hard boundary. head sampling rate ranges from 0 to 1 ; at 0.01 , only one out of one hundred requests is logged. A zero row error query over sampled data may be useful for trend estimation, but it cannot deterministically clear one known request. The same documentation notes that the service can apply a 1% sample after an account exceeds its daily log limit. Record the effective sampling policy, not just the intended configuration. Retention makes an old window unknowable. The documented maximum is three days on Workers Free and seven days on Workers Paid. If an incident window ended before the retention boundary, classify it window expired . Expanding or rewording the query cannot recover data that is no longer stored. Use this order for each investigation: 1. Pin scope. Capture opaque, non secret references for the authorized account, Worker, and environment. Do not store an OAuth token, request URL, log body, or customer identifier in the health receipt. 2. Check collection. Confirm Workers Logs is enabled for the deployed environment and whether invocation logs are enabled. 3. Record coverage limits. Capture the effective head sampling rate, retention days, and requested start/end timestamps. 4. Discover before filtering. Use observability keys to confirm the required fields exist, then observability values to confirm the Worker or environment value is present. This prevents a misspelled or stale field from looking like a clean result. 5. Run a control query. Query broadly enough to find one known invocation emitted inside the same account, Worker, and window. Use a locally held hashed request marker if you need correlation; never upload the raw marker to a monitoring record. 6. Run the incident filter. Only after the control appears should a zero row error filter be considered a candidate for healthy empty . A compact receipt can preserve the decision without preserving log content: The account and Worker references are correlation keys, not secret bearing identifiers. The receipt deliberately excludes prompts, log messages, headers, request URLs, tool arguments, and OAuth material. Route nine states instead of rendering one green result The inspectable artifact accompanying this article replays nine content free cases. Its precedence rule is intentionally conservative: State Evidence Operator action needs auth The remote server is not authorized Route to the account owner; do not label the Worker unreachable scope unresolved Account or Worker reference is missing Resolve the exact account, deployment, and environment collection disabled Workers Logs or invocation logs is off Decide whether to enable collection and redeploy window expired The window predates retained data Mark the historical verdict unavailable query failed Schema discovery, timestamps, or query execution is invalid Repair the query before interpreting row count sampled unknown Zero rows with head sampling below 1 Treat absence as non deterministic coverage unknown Zero rows and the known control invocation is missing Investigate scope, filter, ingestion, or collection delay incident found The filtered query returns one or more matching rows Investigate the returned evidence healthy empty Zero filtered rows plus complete coverage and a found control Clear only this filter, scope, and time window The classifier checks preconditions before looking at filteredRows . That order prevents the most common false green: seeing zero and stopping before asking whether there was any valid dataset to search. Run the fixture locally: The nine fixtures produced one case in each state and all three tests passed: The falsifiable part is simple. Take the healthy empty fixture and remove the control receipt: its state becomes coverage unknown . Lower sampling from 1 to 0.1 : it becomes sampled unknown . Add three filtered rows: it becomes incident found . The row count has meaning only after the evidence path is established. A verified empty log window is still not an agent outcome healthy empty is deliberately narrow. It means the selected Cloudflare Workers log filter returned no matching rows in a covered window. It does not mean the Worker produced the correct response, a downstream write committed once, a scheduled job delivered its artifact, or the user's broader agent task succeeded. Cloudflare's Workers observability overview separates logs, traces, metrics, analytics, and exported telemetry. Each surface answers a different question. A clean error filter can coexist with a wrong business result. A successful invocation log can coexist with a missing destination record. A known control request can prove query coverage while saying nothing about an unrelated queue consumer. Add an outcome receipt outside the log query when the incident involves a user visible effect: a file hash, database version, public response, queue acknowledgement, or another deterministic destination check. If the effect might have occurred but the receipt is absent, do not retry automatically at a side effect boundary. Reconcile first. There are also privacy limits. A control probe should be synthetic, bounded, and easy to identify without placing a secret in logs. The health receipt should retain hashes and states, not request bodies. Cloudflare documents that oversized logs can be truncated; a present row is not proof that every expected field survived. Inspect the $cloudflare.truncated boundary when the diagnosis depends on log content. The Cloudflare Observability MCP server is documented as a work in progress, so tool names and behavior can change. Re run field discovery, pin the evidence date in incident reports, and treat stale tool assumptions as a query failure rather than a healthy result. Sidewisp is currently in private preview. Its production monitoring adapters and recovery systems are not generally shipped. The method here is a local operating pattern, not a claim that Sidewisp currently connects to Cloudflare accounts, queries live Workers, or fixes incidents. The useful rule is smaller: never promote “zero rows” to “healthy” until a known event proves that the exact dataset, scope, window, and collection policy were capable of returning evidence. That turns an MCP response into an auditable decision without pretending that logs alone prove the outcome.