Random Hi Jetpack! All systems go error

Hi @batt4christ

We see this error occasionally on sites hosted on GoDaddy using the Sucuri firewall.

In short, the quick fix is to use the “Site caching” option instead of “Full caching” in the Sucuri settings.

https://kb.sucuri.net/firewall/Performance/caching-options

Can you give that a try and see if that fixes things?

Don’t think we are using the Socuri firewall –

Hi @batt4christ

It may be enabled on the server side of things. Can you check with your host on this? This is a very specific error that we’ve only seen with GoDaddy sites using the Sucuri firewall.

Hello @batt4christ,

It’s been one week since this topic was last updated. I’m going to mark this thread as solved. If you have any further questions or need more help, you’re welcome to open another thread here. Cheers!

This was NOT solved. I was unable to find any evidence of proof that what was suggested as the possible cause, is actually active on our site. Seems to be an effort to deflect blame.

Hello @batt4christ

This is not an effort to deflect blame. The error you reported is very specific and has only been seen in the situations described earlier.

Another thing to look at is that when Jetpack attempts to access https://fbccavesprings.com/xmlrpc.php we’re seeing this error message:

The server has responded with a 429 response code, indicating explicit rate limiting. The user will need to speak with their host to ensure that Jetpack or the mobile app in question has unlimited access to XMLRPC. The host may need to whitelist our IP range,
which can be found at https://jetpack.com/support/hosting-faq/.

Can you please check with your host about this message and allowlisting the addresses on that page? Also perhaps ask them if the Sucuri firewall is enabled on your site?

Just spent 30 minutes on the phone with web host tech support. He went in and said there is no limiting of XMLRPC, nor is Sucuri firewall in any part of this – as it is not installed in my site/hosting server. He loaded our site on multiple devices on his end and did not get the error, and it seems that I can’t cause the original error on any browser – so some kind of transient/intermittent issue?

I also forwarded the last message regarding limits and to check with web host. That was a dead end as, according to them, none is applicable to our hosting.

Hi @batt4christ –

Thanks for checking in with your host.

When we try to access the xmlrpc.php file, we are getting this error:

Perhaps the specific timestamps could be of use to your host? Something is indeed blocking us. It looks they may be using Cloudflare.

Let us know what you find out.

This seems to be a caching issue, caused by the Jetpack uptime monitor. What happens is, when a request for the site’s homepage comes from the Jetpack monitor server, the site returns that text instead of the actual site content.

However, if that page gets cached upstream somewhere (Sucuri, Cloudflare, Varnish, wherever), it can end up being served to all visitors instead of the actual homepage.

This can probably be fixed very easily for everyone forever on Jetpack’s side, by having the monitor server add a query string to the request url like https://example.com/?jetpack=1 so it wouldnt be cached for visitors not using that same query.

Turning off monitoring in Jetpack will also fix it on a per-site basis, but then you don’t have site monitoring sooooo..

Thank you, jailer for acknowledging what I was thinking was the problem (I didn’t know the exact issue – but figured it was something like that). Alas – how do I fix it?

Hi @batt4christ –

Unfortunately, you will need to work with your host to adjust the caching so that this doesn’t happen.

Your site appears to be hosted by GoDaddy, who owns Sucuri, so it is possible that this is happening at the network level and that the person you spoke with isn’t aware that this is happening.

Alternatively, you can turn off Jetpack Monitor.

I have “worked with” my host – and they place the blame directly on the plugin. I have no further options on that end. But it appears that jziller1’s post above is accurate.

@batt4christ thanks. I have passed that suggestion on to our developers for consideration. We’ll reply here when we have an update on that.

Howdy all. I’m one of the development leads for Jetpack.

I’m trying to reach out to folks at GoDaddy about this issue to discuss it further and I’m really sorry for all of the hassle y’all have experienced. It is frustrating.

In the end, that text string is something that they added to their systems to respond to a request from Jetpack. We aren’t looking for it—we ignore the body of the site completely, only looking at the status code on the request—so there’s no reason on our end to have that text there.

I’m not keen on putting in a workaround for a host-specific issue when that issue was created to be a client-specific workaround by them.

Ideally, we can work with them to determine why they added it so we can address _that_ issue. I am surprised they added a client-specific response without adding a no-cache header to prevent it from being cached for other visitors (or their caching solution isn’t respecting it—I’m not sure what is happening there).

Again, I’m sorry for the hassle and I want to find a sustainable resolution to this quickly. If you have any ticket numbers from your interactions with GoDaddy, please let me know so I can reference them when/if I’m able to reach someone on their engineering teams.

Thank you!

Hello again!

I just spoke to a product manager at GoDaddy who confirmed their CDN had some updates and was a bit overaggressive in their caching in the instance of this special response. The situation for the caching aspect is resolved. Y’all should not see that response in the future as part of the caching.

We are working together on the question for the special “Hi Jetpack” response so we can hopefully remove it so it doesn’t become a stumbling block again.

Thanks all for your patience and for using Jetpack!