Allow CuliPulse through your firewall

If your site sits behind a firewall, a WAF, a CDN or bot protection, it may refuse CuliPulse’s checks. The monitor then shows HTTP 403 (forbidden), HTTP 429 (rate limited), or a connection that fails or times out, even though your site works fine in your browser. Allowing CuliPulse’s checks fixes that.

This page applies to checks from the shared locations. A check from your own agent comes from the address of the machine the agent runs on, which you already control.

The addresses CuliPulse checks from

Every HTTP, TCP, UDP and ping check from a shared location comes from one of these addresses:

Location	IPv4 address
Asia-Pacific (Singapore)	51.79.221.153
Europe (Frankfurt)	54.38.158.253
North America (Montreal)	144.217.94.235

• Checks are sent over IPv4 only. You don’t need to allow any IPv6 address.
• Allow all three, even if your monitors use only some locations today, so a location you add later isn’t blocked.
• Domain, DNS and service-status monitors never connect to your servers, so they need nothing allowed.

When these addresses change

You get 14 days’ notice before any change:

• A new address is added to this page and announced in the changelog at least 14 days before it starts sending checks.
• An address being retired keeps sending checks for at least 14 days after we announce its removal, so you can update your rules without a gap.

Choose how to allow the checks

Pick the method that fits your setup. They’re listed from the most secure to the least.

1. A secret header (best for a WAF, CDN or bot protection)

Add a header with a secret value to your monitor, then tell your protection to let through any request carrying it. Only your monitor sends that value, so nobody else can use it to get past your protection.

1. Make up a long random value. For example, run openssl rand -hex 24.
2. Open the monitor, click Edit and open Advanced. Under Secret headers, click + secret header and enter a name such as X-CuliPulse-Key and your value. It’s encrypted and never shown again.
3. In your protection settings, add a rule that lets through requests where that header equals your value. Have it skip only what was blocking the checks, such as rate limiting or bot protection.

On Cloudflare, for example: go to Security rules, choose Create rule → Custom rules, and use the expression (http.request.headers["x-culipulse-key"][0] eq "your-value") and the action Skip, then pick what to skip, for example the rate-limiting rules and Super Bot Fight Mode.

Note

• Secret headers are sent only by the shared locations. Your own agents never receive secrets, so use this method only on monitors that check from shared locations. See Check types for how secret fields work.
• A secret header isn’t sent when your address redirects to a different site (for example www.example.com to example.com), and a check with one won’t follow a redirect from https:// to http://. Set the monitor to the final address.
• On Cloudflare’s Free plan, Bot Fight Mode can’t be skipped by any rule. If it blocks the checks, turn it off or move to a plan with Super Bot Fight Mode, which can be skipped.

2. The addresses (best for a firewall or a cloud security group)

These addresses are shared by every CuliPulse account

Any CuliPulse account can point a monitor at your server from the same addresses. Its checks can send any request method, headers and body, and can test what your page returns. So:

• Allow only what the check needs: the one port, and on a WAF the one page your monitor checks.
• Never use these addresses to skip your WAF’s attack protection (managed rules), or to protect something private like an admin page or an internal API. For that, use a secret header, or run your own agent inside your network.

Allow incoming traffic from the three addresses above, on the port your monitor checks. For a ping monitor, allow ICMP echo requests from them.

• AWS security group: add an inbound rule per address, with the source set to 51.79.221.153/32 (and the same for the other two) and only the port your service listens on.
• nginx: add allow 51.79.221.153; (one line per address) before your deny rule, inside the location your monitor checks.
• Cloudflare: go to Security rules, choose Create rule → Custom rules, set the action to Skip, and limit the expression to the page you monitor, such as (ip.src in {51.79.221.153 54.38.158.253 144.217.94.235} and http.host eq "example.com" and http.request.uri.path eq "/health"). Skip only the rate-limiting rules and Super Bot Fight Mode, not the managed rules. Bot Fight Mode (Free plan) can’t be skipped by any rule; see the note under method 1.

If your site is behind a CDN or a proxy, set the rule on the CDN or proxy. Your own server sees the CDN’s address, not CuliPulse’s.

3. The User-Agent (only if nothing else works)

Unless you set your own User-Agent header on the monitor, every HTTP check identifies itself with a User-Agent that contains culipulse-agent. Some tools can allow requests by User-Agent.

Caution

Anyone can send a request with any User-Agent, so a rule based on it lets through anyone who copies it. Prefer a secret header or the addresses.

Check that it works

1. For an HTTP monitor, run Diagnose (see Run a check on demand). It checks from one of the monitor’s locations, and should show your site’s normal answer, for example HTTP 200.
2. Open the monitor’s Checkpoints tab after the next checks. Every location should show your site as up.
3. If a location still gets 403 or 429, look in your firewall or protection logs for the refused request and which rule refused it.

Still stuck? See Why does it say down when my site is fine?

Alerts sent to your webhook

These addresses are only for checks. Webhook alerts are sent from a different network whose addresses aren’t fixed. To make sure a webhook request is really from CuliPulse, verify its signature instead of allowing addresses.