If an uptime monitor reports 403 or 503 on every check while the site loads normally in your browser, bot protection (a WAF, CDN bot management or rate limiting) is almost certainly blocking the checker, not taking the site down. Fix it by allowlisting the checker's IP addresses or user agent, or a secret request header sent by the monitor.
How to tell a block from an outage
A real outage is messy. Response times spike, errors vary, and the failure usually starts and stops at identifiable moments. A bot block is unnaturally tidy: the same status code on every check, a fast response time (the firewall answers immediately, it never reaches your application), and a failure that began the moment you created the monitor or changed a security setting.
- Looks like a blockIdentical 403 or 503 on every check, 40-150ms response times, and the page loads fine from your laptop.
- Looks like an outageTimeouts, connection resets, 5xx that come and go, or slow responses that degrade before failing.
- The giveawaySutramX labels a detected block as "Blocked by bot protection (WAF)" rather than a generic error, and names the vendor when it can identify one.
Why it happens to monitoring specifically
Bot protection scores every request. Uptime checks trip several signals at once through no fault of their own: they come from datacenter IP ranges rather than home broadband, they run on a fixed schedule that no human reproduces, and they are plain HTTP clients that do not execute JavaScript. Products like Cloudflare Bot Fight Mode and Vercel Attack Challenge Mode block that profile by default.
This is not a flaw in the protection or in the checker. Both are doing their job. Your firewall has not been told that this particular automated visitor is one you asked for.
A monitor that disguises itself to slip past your security is a monitor you cannot trust, and it would tell you nothing about what real visitors experience. SutramX identifies itself honestly and asks to be let through instead.
Fixing it: three options
- Allowlist the IP addressesStrictest and most reliable. Our current addresses are published at sutramx.com/bot and as a plain-text list at sutramx.com/bot/ips.txt.
- Allowlist the user agentSimplest. Match the substring SutramX-Monitor in your WAF rules. Anyone can send that string, so prefer IP allowlisting for sensitive endpoints.
- Use a secret headerMost precise. Add a custom request header with a secret value to your monitor, then allowlist requests carrying it. Survives any future change to our IP addresses.
On Cloudflare's Free plan, Bot Fight Mode cannot be bypassed by WAF custom rules, a Skip action or Page Rules, so a user agent rule will not help. Either add an IP Access Rule with the action Allow for each address in sutramx.com/bot/ips.txt (Bot Fight Mode does not challenge a request an IP Access Rule has already allowed), or turn Bot Fight Mode off. On Pro and above, Super Bot Fight Mode can be skipped with a custom rule whose action is Skip with "All Super Bot Fight Mode rules" selected. SutramX has applied to Cloudflare's Verified Bots program and signs its requests with Web Bot Auth.
Step-by-step instructions for Cloudflare, Vercel, AWS WAF, nginx, Apache, and WordPress security plugins are on the bot information page at sutramx.com/bot.
Monitoring a site you do not control
If the target belongs to someone else — a vendor, a partner, an API you depend on — you cannot allowlist anything, and no amount of configuration on your side will change that. Send them the bot information page and ask them to allow the checker.
If they will not, monitor something they do expose deliberately: a documented public API endpoint, a status endpoint, or a health check URL. Those are usually exempt from bot protection because they exist to be polled by machines.
Why we still call it down
When a WAF blocks a check, your site is probably healthy — but we genuinely do not know that, because we never reached it. Reporting "up" on that basis would mean claiming an availability we did not verify, which is the one thing a monitoring tool must never do.
So a block stays a failure, labelled for what it is. If a specific monitor checks a target you know will always block us, you can suppress alerts for the "Blocked by bot protection" error type in that monitor's alert settings while leaving every genuine failure mode alerting.