Monitoring a Site Behind a Firewall or WAF

If your website is protected by a WAF, CDN, or bot-protection system — such as Cloudflare, AWS WAF, Sucuri, or a hosting firewall — it may challenge, rate-limit, or block Hoppla's monitoring probes even though your site is perfectly healthy for real visitors.

Typical symptoms:

• A check passes when you open the site in your browser, but Hoppla reports it as down, timed out, or degraded.
• The SSL check shows "Couldn't connect to check the certificate" even though the certificate is valid.
• Intermittent failures or warnings that clear on a manual Run Now and then come back.

This happens because security systems often block connections from data-center IP ranges or from non-browser clients. The fix is to allowlist Hoppla so your monitors report accurately.

There are two ways to allowlist Hoppla, depending on the check type.

1. By User-Agent — recommended for HTTP-based checks

Hoppla's HTTP-based checks identify themselves with a self-describing User-Agent:

HopplaBot/1.0 (+https://hoppla.dev/bot)

Allowlisting this User-Agent covers every check that speaks HTTP: Uptime, Security Headers, Robots.txt, Sitemap, Broken Links, Mixed Content, Redirects, Application Health, Core Web Vitals, Lighthouse, and the GEO Audit.

White-label / reseller portals

If you access Hoppla through a reseller or white-label portal, your provider may have configured a custom monitoring User-Agent. In that case, allowlist the User-Agent your provider gives you instead of HopplaBot.

Cloudflare

1. Open your Cloudflare dashboard and select the zone (domain) you monitor.
2. Go to Security → WAF → Custom rules → Create rule.
3. Give it a name, e.g. Allow Hoppla monitoring.
4. Set the matching expression:
   • Field: User Agent
   • Operator: contains
   • Value: HopplaBot
5. Set Action to Skip, and under "Skip the remaining …" enable:
   • All remaining custom rules
   • Rate limiting rules
   • Super Bot Fight Mode / Bot Fight Mode (under "Also skip")
6. Deploy the rule, and drag it to the top of your custom-rules list so it is evaluated before any block/challenge rules.

If you use Bot Fight Mode or Super Bot Fight Mode, the Skip rule above is what prevents them from challenging HopplaBot. Avoid enabling "Under Attack Mode" for the whole zone — it presents a JavaScript challenge to every client, including monitors. If you need it, scope it to specific paths rather than the entire site.

Other WAFs

The principle is the same everywhere — allow requests whose User-Agent header contains HopplaBot:

• AWS WAF: add a string-match rule on the User-Agent header (contains HopplaBot) with action Allow, ordered before your block rules.
• Sucuri / hosting firewalls: add HopplaBot to the User-Agent allowlist (or whitelist) in the firewall settings.

2. By IP address — required for SSL, TCP, and Ping checks

The SSL certificate, TCP port, and Ping (ICMP) checks connect at the network/transport layer — a raw TLS handshake, TCP connection, or ICMP echo. They do not send a User-Agent, so they can only be allowlisted by source IP.

Because Hoppla's monitoring IP ranges can change over time, they are not listed publicly. Request the current monitoring egress IPs from [email protected] (or from your reseller / provider if you use a white-label portal), then allowlist them:

• Cloudflare: Security → WAF → Tools → IP Access Rules → add each IP with action Allow, scoped to the relevant zone. (Alternatively, create a WAF custom rule matching IP Source Address is in your list with action Skip.)
• Other WAFs / firewalls: add the IPs to your allowlist / firewall exception list.

How Hoppla handles a blocked SSL probe

A pure connection failure (a timeout, refusal, or reset while opening the TLS/TCP/ICMP connection) is not treated as a certificate problem or a hard outage — reachability is measured by the Uptime check. So a tarpitted SSL probe is recorded as a non-paging warning ("couldn't connect to check the certificate"), never a "certificate invalid" incident. Allowlisting Hoppla removes even those warnings and keeps your checks cleanly green.

Verifying it worked

After you've added the allowlist rule, open the affected monitor, switch to the relevant check tab, and click Run Now (or wait for the next scheduled run). The check should turn green. If it doesn't, double-check that the allow/skip rule is ordered above any blocking rules in your WAF.