1020 means a Cloudflare firewall rule matched the request and blocked it — sometimes correctly, sometimes blocking your own users, your monitoring, or your app's own callbacks.
Rules keyed on country, ASN, URI patterns, or user-agent can catch legitimate traffic — e.g., blocking all 'curl' user agents also blocks your own health checks.
Rules like SQLi detection can trigger on query strings containing code-ish values — ?redirect=https:// or base64 params are classic false positives.
# Cloudflare dashboard → Security → Events: filter by the visitor's IP/time; the log names the exact rule and action# note the matched rule ID, path, user agent — decide: legitimate traffic (tune rule) or attack (keep block)# (rule expression): (http.user_agent contains "UptimeChecker") or (ip.src in {your-office-cidr}) → Skip / Allow# Security → WAF → ruleset → find the rule ID from the event log → disable that one rule or set its action to Log firstSet new rules to 'Log' action for a week before 'Block' — you learn the blast radius before feeling it. Monitoring that goes through Cloudflare needs a stable, allowlisted fingerprint (IP or custom header), or your own alerts go blind.
Their user agent or source ASN matched a block rule. Add a Skip/Allow exception for the checker's IP or a custom header it sends — better than opening the rule for everyone.
Usually not — it's server-side policy, not their machine. If a legitimate visitor reports it, pull their IP from your analytics, find the rule in Security Events, and tune the rule.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.