• Looking for suggestions and/or a solution for a problem with Jetpack’s monitor feature.

    Whenever we use the Cloudflare ‘under attack’ mode, Jetpack starts sending site is offline emails.

    Is there any way to fix this that still allows us to protect our sites (and the server) from these (much more frequent) attacks?

    Thanks
    PPNSteve

    Your thoughts and 2 cents worth can help.

    The page I need help with: [log in to see the link]

Viewing 1 replies (of 1 total)
  • Plugin Contributor Stef (a11n)

    (@erania-pinnera)

    Hi there, @ppnsteve,

    That’s great question, and yes, what you’re seeing is expected behaviour given how Jetpack Monitor and Cloudflare’s “Under Attack” mode interact.

    When “Under Attack” mode is active, Cloudflare places a JavaScript challenge page in front of all traffic before serving your site. Jetpack Monitor sends a simple HTTP HEAD request using the user agent jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com); it can’t solve the JS challenge, so it sees a non-200 response and flags your site as offline. That’s a false positive created by an intentional security layer.

    You have a few options:

    1. Create a Cloudflare WAF bypass rule for the Monitor agent (which we recommend). You can tell Cloudflare to skip the challenge specifically for Jetpack Monitor requests:

    • Go to Cloudflare Dashboard → Security → WAF → Custom Rules
    • Create a rule: User Agent contains jetmon/1.0 → Skip (bypass challenge)

    This lets Monitor through while keeping “Under Attack” mode enabled for everyone else. It’s the cleanest solution.

    2. Use more targeted Cloudflare protections instead of full “Under Attack” mode. If the attacks aren’t severe enough to require a blanket challenge, these alternatives are less likely to interfere with uptime checks:

    • WAF custom rules targeting specific threat signatures
    • Rate limiting
    • Bot Fight Mode or Super Bot Fight Mode

    3. Accept the trade-off, just temporarily. If “Under Attack” mode is only used during active attack windows, the false offline alerts are expected and will stop once you disable it.
    You can also confirm Monitor is being blocked by running this cURL command (replace the URL with your domain):

    curl -IA "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)" https://yoursite.com

    A 200 response means Monitor can reach your site. Anything else (like a 403 or a Cloudflare interstitial) confirms the block.

    We have reported this behaviour internally, so if we find a better solution to address it, we’ll develop it accordingly (still I can’t promise any ETA for this to be shipped).

    Hope that helps for now!

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.