Allow UptimePad checks
If your firewall or bot protection blocked a request from UptimePad, here is how to let our checks through. A block does not mean your site is down for real visitors. It means our checker was filtered before it reached your server.
Our checker
UptimePad makes plain HTTP and HTTPS requests on a schedule. No headless browser, no page rendering, no scraping. Every request carries this User-Agent:
UptimePadBot/2.0 (+https://uptimepad.com/bot)
Allow by User-Agent (Cloudflare)
Add a WAF custom rule with the action set to Skip (or Allow), matching our User-Agent:
(http.user_agent contains "UptimePadBot")
Skip the managed rules, bot fight mode, and rate limiting for that rule so the check is never challenged.
Allow by User-Agent (Nginx, Apache, generic WAF)
Add an allow rule for any request whose User-Agent contains UptimePadBot. Place it ahead of any bot-blocking or rate-limit rules so it takes priority.
Why you might see a 403 or 429
A 403 Forbidden usually means a WAF or bot rule blocked the check. A 429 Too Many Requests means a rate limit was hit (common on shared datacenter IPs). In both cases your site is most likely up for real visitors. UptimePad reports these cases plainly so you can tell a filtered check apart from a genuine outage.
Stricter allowlists
If your firewall allowlists by IP rather than User-Agent, contact support from your account and we will share the current egress IP set for your monitors.