# Cloudflare adds a failed-detections field so rules can react when security checks error out

Cloudflare's changelog documents a new cf.appsec.request.failed_detections array that reports which security detections failed on a request, letting zone- and account-level rules branch on those failures.

Canonical URL: https://freelancenews.online/news/cloudflare-adds-a-failed-detections-field-so-rules-can-react-when-11ca60b0
Published: 2026-10-09T09:17:15.914Z
Updated: 2026-10-09T09:17:15.914Z
Source published: 2026-10-09T00:00:00.000Z
Event date: Not established
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

Cloudflare has documented a new field, cf.appsec.request.failed_detections, that can be referenced inside rules to control how requests are handled when a security detection reports a failure. The change is described in the company's developer changelog, which is the sole source for this report.

For this field, an Array<String> holds the detection IDs. According to the changelog, the failures it reports originate from multiple sources: WAF attack score, content scanning, leaked credentials detection, attack signature detection, and AI prompt detections. Personally identifiable information, prompt injection, custom topics and unsafe topics are all covered by those AI prompt detections.

The changelog is explicit that the field does not change how detections themselves behave. Its stated purpose is narrower: it gives rule authors a way to choose how to handle requests that carry reported failures. That distinction matters for anyone maintaining a WAF configuration, because adding the field to a rule expression changes routing logic, not detection logic.

Two documented behaviours define the field's edge cases. When no failures are reported, the field returns an empty array. And the field is available on all plans, but the changelog states that a plan must still include the detections and rule features the author wants to use. In other words, access to the field is not the same as access to the underlying detections.

The changelog lists where the field can be used: custom rules at both zone and account levels, rate limiting rules at both zone and account levels, and Request Header Transform Rules at the zone level. That is a specific and bounded set of rule types rather than a blanket statement about every Cloudflare rules product.

Two example expressions are given. To match any reported failure, the changelog shows len(cf.appsec.request.failed_detections) gt 0. To match a reported leaked credentials detection failure specifically, it shows any(cf.appsec.request.failed_detections[*] eq "waf_credential_check"). These illustrate the two broad patterns the field supports: a catch-all check on array length, and a targeted check against a named detection ID.

For freelancers and small studios who manage client sites on Cloudflare, the practical value is in the targeted form. A rule that branches on a single detection ID lets an operator treat one class of failure differently from the rest, while the length check lets them treat any failure as a single condition. Which of those is appropriate depends on the site, and the changelog does not recommend one over the other.

The changelog does not state what a rule should do with a failed detection, and it does not describe default handling. It only says the field lets authors choose how to handle requests with reported failures. Any decision about blocking, logging or transforming such requests is left to the rule author and is not specified in the supplied material.

Nor does the changelog explain why a detection might report a failure, how long a failure persists, or whether failures are surfaced anywhere outside rule expressions. Those questions are unanswered in the source and should be treated as open rather than assumed.

The changelog also does not provide pricing, plan-tier specifics beyond the general statement that all plans can use the field, or a migration path for existing rules. It points readers to a separate failed detections field reference for more information, which is not included in the supplied evidence.

The event date is not established by the supplied material. The changelog URL carries a 2026-10-09 path segment, but the excerpt text does not state a publication or release date, so no event date is asserted here.

For this audience, the sensible reading is that this is a configuration-surface addition rather than a new detection capability. Developers who already write Cloudflare rule expressions gain one more field to test against; designers and other freelancers who inherit a client's Cloudflare setup may encounter it in rules written by someone else.

The honest limitation is that everything above rests on a single changelog entry. There is no independent confirmation, no field reference in the evidence, and no statement about behaviour under failure conditions beyond the empty-array case. Treat the examples as documentation samples, not as tested configurations.

## Key points

- Cloudflare documents cf.appsec.request.failed_detections, an Array<String> of detection IDs reporting failures from content scanning, WAF attack score, attack signature detection, leaked credentials detection and AI prompt detections.
- The field does not alter detection behaviour; it is intended for use in rules to decide how requests with reported failures are handled.
- It returns an empty array when no failures are reported, and is available on all plans, though the relevant detections and rule features must still be included in the plan.
- Documented usage is limited to custom rules and rate limiting rules at zone and account levels, plus Request Header Transform Rules at the zone level.
- The changelog supplies two example expressions: a length check for any failure, and an equality check against the "waf_credential_check" detection ID.

## Practical implications — editorial interpretation

Editorial interpretation: for developers maintaining Cloudflare rules, this adds a conditional input that can distinguish a single failed detection from any failure, which is useful when one detection class needs different handling than the rest. It does not add a new detection, so it should not be treated as a security improvement on its own.

## Limitations and unknowns

Based on one Cloudflare changelog entry. No field reference, pricing detail, release date, or independent confirmation is present in the evidence. The changelog does not explain why detections fail, how long failures persist, or what default handling applies, and no configuration was tested for this report.

## Sources

- [1] developers.cloudflare.com: Changelog
  https://developers.cloudflare.com/changelog/post/2026-10-09-failed-detections/
  Retrieved: 2026-10-09T09:17:01.814Z

## Claim references

- Cloudflare documents a cf.appsec.request.failed_detections field typed as an array of detection ID strings. [source 1]
- The field reports failures from content scanning, WAF attack score, attack signature detection, leaked credentials detection and AI prompt detections. [source 1]
- The field does not change existing detection behaviour and is meant for use in rules to handle requests with reported failures. [source 1]
- When no failures are reported the field returns an empty array, and it is usable on all plans provided the plan includes the relevant detections and rule features. [source 1]
- Documented usage covers custom rules and rate limiting rules at zone and account levels, and Request Header Transform Rules at the zone level. [source 1]
- The changelog gives example expressions for matching any failure and for matching a leaked credentials detection failure by ID. [source 1]