Allow Spot Downtime through your firewall
Is your firewall blocking us?
If your site works in a browser but its monitor is down, open the monitor and look at Recent checks. These usually mean something in front of your site turned our request away, not that your site is down:
| What the check shows | Usual cause |
|---|---|
HTTP 403 | A WAF rule, bot protection or an IP allowlist |
HTTP 429 | Rate limiting |
HTTP 503 | A challenge page (“checking your browser”) or a CDN rule |
| Connection reset, stream error, timeout | Traffic from our address or user agent is dropped silently |
Common sources are Cloudflare (Bot Fight Mode, WAF custom rules, security level), AWS WAF and security groups, nginx or Apache rules, Wordfence and similar plugins, and hosting firewalls.
1. Send a secret header (recommended)
Add a header only Spot Downtime knows to the monitor, then tell your firewall to let requests with it through. It works whatever address our checks come from, and nobody can fake it without the secret.
In the app, edit the monitor and add a line to Headers (website and API monitors both have it). Use a long random value, like a password:
X-Uptime-Check: 9f1c6a0e5b7d4e2a8c3bCloudflare: go to Security → WAF → Custom rules, create a rule with this expression, choose the Skip action, and skip all the remaining custom rules, rate limiting rules, managed rules and Super Bot Fight Mode:
any(http.request.headers["x-uptime-check"][*] eq "9f1c6a0e5b7d4e2a8c3b")AWS WAF: add a rule to your web ACL, above your blocking rules: a string match on the single header x-uptime-check, match type Exactly matches string, with your value, and action Allow.
nginx: for example, leave checks out of rate limiting (requests with an empty key aren't limited):
map $http_x_uptime_check $limit_key {
"9f1c6a0e5b7d4e2a8c3b" "";
default $binary_remote_addr;
}
limit_req_zone $limit_key zone=perip:10m rate=10r/s;Everyone in your workspace can see a monitor's headers. Use a value made just for this, never a real password or API key.
2. Allow our IP addresses
The same list is always available as JSON and as plain text (one address per line) for scripts that update firewall rules.
| Where | How |
|---|---|
| Cloudflare | Security → WAF → Tools → IP Access Rules: add each address with the action Allow. |
| AWS security group | Add an inbound rule for HTTPS (443) from 203.0.113.10/32. |
| AWS WAF | Create an IP set with the addresses and a rule that Allows it, above your blocking rules. |
| Hosting or server firewall | Add the addresses to the allowlist in your host's control panel. |
nginx and Apache, for a site restricted to known addresses:
allow 203.0.113.10;Require ip 203.0.113.10Ping and TCP port monitors come from the same addresses. Allow ICMP echo requests for ping monitors, and the monitored port for TCP monitors.
3. Match our user agent
Website and API checks identify themselves with this user agent:
SpotDowntime/1.0 (+uptime monitor)Anyone can send a user agent, so only use it for low-risk rules, like leaving our checks out of rate limiting or analytics. Don't use it to skip security rules. Use the secret header for that.
Check that it works
After changing your rules, open the monitor in the app and click Check now. It should come back up within a few seconds. If it's still blocked, the check's error and status code show what's in the way.
If our addresses ever change, this page and the JSON list show the new ones, so check them before you change firewall rules. Still stuck? Contact us with the monitor's name.
Something missing or unclear? Tell us.