Firewall & WAF Whitelisting
If your site uses a Web Application Firewall (WAF) or CDN with bot-protection - such as Cloudflare, Akamai, Sucuri, or Imperva - it may block our monitoring requests and report your site as DOWN even though it’s working fine for real visitors.
This guide explains why that happens and how to fix it.
Why Does This Happen?
WAFs and CDN bot-protection services analyze incoming requests to distinguish real browsers from automated traffic. If a request looks like it comes from a bot, they may return a 403 Forbidden or a challenge page instead of the actual content.
Our monitoring system sends browser-like HTTP headers (including a standard User-Agent) to minimize this, but aggressive bot-protection rules may still flag our requests - especially if:
- Your WAF is set to a high security level (e.g. Cloudflare’s “I’m Under Attack” mode)
- You have custom firewall rules that block non-browser traffic
- Rate-limiting rules are triggered by periodic checks
How to Identify This Issue
You’re likely experiencing WAF blocking if you see:
- Monitor shows DOWN but the site loads normally in your browser
- Monitor results show an HTTP 403 status code
- Response times are unusually fast (under 50ms) - the WAF rejected the request before it reached your server
- The
detected_cdnfield shows a CDN provider like Cloudflare, Akamai, etc.
Our Monitoring IP Addresses
To whitelist our monitoring traffic, allow requests from the following IP addresses in your firewall or WAF settings:
| IP Address |
|---|
209.126.0.56 |
51.38.115.44 |
91.194.91.7 |
149.102.146.185 |
85.239.233.60 |
206.189.36.47 |
103.125.216.51 |
These are the only IPs our monitors will connect from. We recommend whitelisting all of them to ensure checks from every monitoring location succeed.
How to Whitelist by Provider
Cloudflare
- Go to Security → WAF in your Cloudflare dashboard
- Click Create rule
- Set the rule to Skip (allow) when the IP Source Address is in
{209.126.0.56, 51.38.115.44, 91.194.91.7, 149.102.146.185, 85.239.233.60, 206.189.36.47, 103.125.216.51} - In the skip settings, check Skip all remaining custom rules and Skip all rate limiting rules
- Save and deploy the rule
- Make sure this rule is above (higher priority than) any block rules
Akamai
- Go to Security → IP/Geo Firewall
- Add our IP addresses to the allowlist
- Save and activate the configuration
Sucuri
- Go to Settings → Firewall in your Sucuri dashboard
- Add our IPs to the Whitelisted IP Addresses list
- Save changes
Imperva (Incapsula)
- Go to Settings → Security → IP Management
- Add our IPs to the Allowlist
- Save the configuration
Generic / Other Firewalls
Add firewall rules that allow inbound HTTP/HTTPS traffic from our IP addresses listed above. The exact steps depend on your provider - consult their documentation for allowlisting IPs.
Our Request Signature
Our monitoring requests identify themselves with the following User-Agent:
Mozilla/5.0 (compatible; HSPBot/1.0; +https://statuspage.me) AppleWebKit/537.36
If your WAF supports User-Agent-based rules, you can also whitelist requests containing HSPBot as an alternative to IP-based whitelisting.
Alternative: Custom Headers
If you cannot whitelist by IP or User-Agent, you can configure your monitor to send a custom header that your server recognizes:
- Edit your monitor in the dashboard
- Scroll to Custom Headers
- Add a secret header, e.g.
X-Monitor-Token: your-secret-value - Configure your WAF to allow requests containing that header
This approach works well when you control both the monitor and the server configuration.
Still Seeing False DOWNs?
If you’ve whitelisted our IPs and are still seeing false DOWN events:
- Check your WAF logs - look for blocked requests from our IPs to confirm they’re being allowed
- Verify all IPs are whitelisted - we monitor from multiple locations, make sure every IP is included
- Check rate limiting - some WAFs have separate rate-limiting rules that may still trigger
- Test with the API - use our API to view raw monitor results and check the HTTP status code being returned