Collect a UTC time window, affected hostname, path and any Ray IDs. Define the question you are investigating, such as a customer block or a burst against one endpoint.

1. Open Security > Analytics and select Events.
2. Set a focused time range and filter by useful fields such as action, service, path or source. Keep track of active exclusions.
3. Expand representative events and inspect the rule, action and request context. One request can generate more than one event.
4. Compare with origin logs and application symptoms. Requests blocked at the edge may never reach the hosting server.
5. Export an individual event or available report where appropriate, sanitise it and record the investigation outcome before changing rules.

The event details should identify the control involved and support a specific corrective action. Compare like-for-like time ranges when evaluating whether a new rule helped.

Sampled logs may omit individual events, especially across broad high-volume windows. Narrow the range and use available plan-specific logging or analytics tools where necessary. An empty filtered list is not proof that no request or security action occurred.

Ask the affected visitor for the public URL, approximate time and the Ray ID shown on the block or challenge page where available. Those details are more useful than disabling several rules to see whether the problem disappears.

In the available Cloudflare events, find the corresponding request and inspect its action, rule and request characteristics. Compare it with a legitimate request that succeeds. Be careful with differences such as a customer's browser request versus an application's server-to-server callback.

How should I create an exception?

Choose the narrowest supported scope that addresses the verified false positive. Preserve the original rule so that you can reverse the change. Avoid a permanent site-wide bypass for a single payment callback or one customer's shared network.

Retest both the previously blocked action and a request that should remain protected. Review subsequent events to confirm the exception behaves as intended. If the request reaches our server but still fails, provide the resulting origin error as well. Cloudflare's decision and the application's response are separate stages, and resolving one does not prove the whole customer journey works.

A single request can trigger several security features and appear as multiple events. Also check sampling, filters, timezones and whether your comparison counts requests, visitors or actions.

• Investigating a Cloudflare WAF false positive with Ray IDs
• Applying an available rate-limit rule to an abused login endpoint
• Comparing Cloudflare analytics with hosting access logs
• Using Cloudflare’s current security controls instead of old security levels

• Cloudflare: Security Events