Case Study: Cloudflare 403 vs Real Downtime

A support team reported "site down" after receiving 403 responses from monitoring checks. End users could still load the homepage in browsers. This case explains how to resolve that contradiction.

Symptoms observed

• Automated checks returned HTTP 403.
• Browser users saw occasional challenge pages, then success.
• No evidence of origin server crashes or 5xx errors.

Diagnostic sequence used

1. Run the URL in Website Checker and capture status text + notes.
2. Check whether response includes bot-protection patterns (Cloudflare challenge hints).
3. Test from browser and compare with server-side check behavior.
4. Inspect WAF/rate-limit policy thresholds in edge settings.

Root cause

The site was online, but WAF settings treated non-browser traffic as suspicious. Synthetic checks were blocked at the edge before reaching full page content.

Fix and validation

• Adjusted bot/WAF rules for expected monitoring behavior.
• Reduced aggressive rate-limit settings for diagnostic endpoints.
• Retested: checker moved from blocked/limited status to stable online responses.

Takeaways

• 403 does not always equal downtime.
• Different request types can receive different outcomes.
• Pair checker status with edge security logs before declaring an outage.

Related reading: 5xx troubleshooting guide and checker methodology.