The IP addresses you need to allowlist for uptime monitoring are the ones your monitoring vendor publishes, and they need adding at every layer that can reject traffic rather than at the first one you think of. Most allowlisting failures are not wrong addresses. They are right addresses entered in one place while a second or third layer, usually the application firewall or the rate limiter, quietly keeps blocking the checks.
This article covers the three layers an allowlist has to cover, why the header approach is more durable than the address approach, how to handle a vendor with many global check locations, and the maintenance this creates that nobody schedules.
The three layers that can block a check
The network firewall. Security groups, cloud firewall rules, and iptables sit in front of everything and are the layer everyone remembers. Allowlisting here is necessary and rarely sufficient.
The application firewall or CDN. Cloudflare, AWS WAF, a load balancer's rule set, or a security plugin inside the application each make their own decisions after the network firewall has already let the packet through. A check that passes the network layer and gets a 403 from the WAF looks identical to a check that was never allowed at all, which is what makes this layer so frustrating to debug.
The rate limiter. Rate limiting counts requests per address over a window and does not care that the address is on an allowlist somewhere else. A one minute check interval from several locations produces steady traffic from a small set of addresses, which is precisely the shape rate limiters are built to stop.
The application itself. Login throttling, bot detection plugins, and country blocking all live inside the application and enforce their own rules. A monitoring check reaching a WordPress site with a security plugin can be blocked by that plugin regardless of what the infrastructure allows.
Why a header beats an address list
IP allowlists have a maintenance problem that is easy to underestimate. Monitoring vendors add check locations, retire ranges, migrate between providers, and expand into new regions, and each of those events silently invalidates part of your allowlist. The failure mode is the worst available: checks from the new range get blocked, your monitor reports the site down, and you spend the first twenty minutes of a false incident investigating a server that is fine.
Sending a secret header with every check and matching on that header removes the whole category of problem. The header does not change when your vendor changes infrastructure, it identifies your specific monitoring configuration rather than a shared pool of addresses, and it is not visible to anyone who is not already receiving your checks. Where the platform supports it, match on the header and use the IP list as a secondary condition rather than the primary one. Where it does not, the address list is what you have, and it needs a review date.
The one situation where addresses are genuinely better is a network firewall that cannot inspect HTTP headers at all, because it operates below that layer. There, addresses are the only tool available, which is another reason to keep the network firewall's allowlist deliberately broad and do the precise matching further up the stack.
Handling a vendor with many check locations
Global monitoring multiplies the problem. Checking from seventeen locations means traffic arriving from at least seventeen different networks, and a rate limit calibrated for one source will behave differently against many. This is generally an advantage rather than a cost, because a regional failure only shows up when you are checking regionally, but it does mean the allowlist has to be complete rather than approximately complete.
Two practical rules make this manageable. First, allowlist the vendor's published range rather than the individual addresses you observe in your logs, because the addresses you happen to see are a subset of the ones that will eventually check you. Second, cover IPv6. A dual-stack monitoring service will use IPv6 where your DNS offers it, and an allowlist containing only IPv4 addresses will block half the checks in a pattern that looks like intermittent packet loss. Whatever your provider publishes is the list to work from rather than anything reconstructed from logs. Odown's documentation covers monitor configuration, and support can confirm the current source ranges for the seventeen check locations if your firewall needs them.
The maintenance nobody schedules
An allowlist is a configuration that decays. The vendor's ranges change, your own infrastructure changes, someone rebuilds a firewall from a template that predates the entries, and a WAF migration carries over the rules that were documented and loses the ones that were not. None of this announces itself. It shows up months later as an outage alert on a healthy site, usually at an inconvenient hour, and usually to somebody who was not there when the allowlist was created.
Three habits prevent most of it. Document why each entry exists, in the rule description rather than in a document nobody opens, so the next person does not delete it during a cleanup. Review the vendor's published ranges on a schedule, quarterly is generous for how long it takes. And when a monitoring alert fires, check whether the response body contains a block page before assuming the server is down, because that one look distinguishes a real outage from an allowlist that expired without telling anyone.
Common mistakes in allowlisting monitoring traffic
Allowlisting at the firewall and stopping. The network layer is the first of three or four places a check can be rejected. A packet that reaches your server can still be blocked by the WAF, the rate limiter, or a plugin.
Building the list from observed log entries. The addresses in your logs are the ones that have checked you so far, not the full published range. Work from the vendor's list.
Forgetting IPv6. A dual-stack monitoring service will use IPv6 wherever your DNS advertises it. An IPv4-only allowlist produces intermittent failures that look like network trouble.
Allowlisting an entire large block. Granting a wide range to bypass security to fix a monitoring problem is a serious trade. Use the vendor's specific ranges, and prefer a secret header where the platform allows it.
Never reviewing it again. Vendor ranges change and firewall rules get rebuilt. An allowlist without a review date fails silently at some point, and the failure arrives as a false outage.
FAQ
Do I need to whitelist IPs for uptime monitoring at all?
Only if something is blocking the checks. Many sites need no allowlisting whatsoever. It becomes necessary when a firewall, WAF, bot protection, or rate limiter starts rejecting the traffic, which often happens months after monitoring was set up.
Is allowlisting a monitoring service a security risk?
It is a small, contained one if scoped properly. Allowlisting specific published ranges to reach specific paths is low risk. Allowlisting a broad block, or exempting the whole site from security features, is where it becomes a genuine exposure.
What should I do when my monitoring vendor changes its IP addresses?
Update the allowlist from the vendor's published list. To avoid depending on that entirely, match on a secret header your checks send, which continues working through any infrastructure change on the vendor's side.
Why do my checks fail even though the IPs are allowlisted?
Almost always another layer. Check the WAF, the rate limiter, and any security plugin inside the application. Reading the response body usually reveals a block page identifying which one rejected the request.
Closing thought
Allowlisting monitoring traffic is one of those tasks that feels finished the moment the first check turns green, which is exactly why it fails later. The layers are the point: firewall, application firewall, rate limiter, application. A check has to survive all of them, and it only takes one of them changing to turn a healthy site into an alert at three in the morning.
Where you have the choice, identify your monitor by something that belongs to you rather than by an address that belongs to your vendor. Odown supports custom headers on every check, which is the durable option, and can confirm source ranges for the cases where addresses are the only tool your firewall understands. Checks run from seventeen locations worldwide, so regional failures are visible rather than inferred. Setup details live in the documentation, and plans start at twelve dollars a month with a fourteen day trial and no card required.
