WP Remote and the Curious Case of Phantom Downtime

When you have a ton of emails, messages, and pings to get through, the last thing you want to see is a down alert for a customer website. 

You stop all the work you’re doing to deal with this crisis—hopefully before the customer is aware their site is down—only to realise it is a false positive. 

Waste of time. Waste of energy. Waste of panic. 

That’s when the annoyance sets in. Why should you pay for a service that doesn’t work like it should?

On top of it, uptime monitoring is the easiest website service: site up, no alert; site down, instant alert. 

It is THAT simple. 

Isn’t it?

Well, not quite. 

The reality is that uptime is straightforward only on the frontend. The backend is a whole different ballgame. 

Security measures evolve daily. Browser standards shift overnight. What worked perfectly yesterday can suddenly break today.

This constant shift in tech creates a unique challenge for services that need to maintain reliable connections. 

It’s like trying to hit a target that never stops moving.

Many of our customers have switched to WP Remote because of excessive false downtime alerts. It is really that disruptive to work.

Keeping uptime monitoring UP

Last week, we saw a massive spike in uptime monitoring alerts. It was immediately evident something had gone wrong. Anomalies are great for identifying issues, after all. 

The downtime alerts were all for sites hosted on Bluehost, HostGator, and iFastNet. Unless there was a major server outage across these web hosts, there was no way these sites were really down. 

This wasn’t a coincidence. Something fundamental had changed on their end. (And it wasn’t the first time something in a web host’s configuration has skewed uptime monitoring data.)

Analyzing the root cause

The team dug deeper, analyzing hundreds of failed monitoring attempts. 

We discovered two changes. 

For sites on Bluehost and HostGator, uptime requests were being blocked at the gate. They had silently changed their ModSecurity systems to better deal with bot attacks. The new rule required the humans_21909=1 cookie to prove the request was from a legitimate source.

Meanwhile, iFastNet had implemented something more complex. Instead of just blocking unknown requests, their servers responded to these with a JavaScript challenge.

The visitor’s browser would execute JavaScript code, which would in turn decrypt a special value and set a cookie. Only then would the request be allowed through to the actual website. 

These measures were designed specifically to separate browsers operated by humans from automated systems.

Uptime monitoring servers ARE automated systems, so they were obviously not getting through.

These security changes didn’t just cause problems for monitoring services. They affect any service that connects to websites through automated requests.

Who solves this problem? 

Is the site owner, agency, web host, or the uptime monitoring service (aka WP Remote) responsible for solving this issue? 

We could ask thousands of customers to solve the problem themselves. Contact your hosting providers and whitelist our IPs. It would be easy. It’s probably what most monitoring services would do.

At WP Remote, though, we take our mission of making site maintenance handsfree very seriously.  

We don’t pass on technical challenges onto our customers.

The WP Remote solution

For the Bluehost and HostGator challenge, our engineers modified our monitoring system to automatically attach the required cookie to every request. Within 24 hours, monitoring for over 5,000 websites was restored without any customer involvement.

The iFastNet challenge required more creativity. Since our monitoring system didn’t use a browser, it couldn’t naturally execute JavaScript or manage cookies the way a browser would.

Rather than accept this limitation, our team built something new: a specialized system that could interpret the JavaScript challenge. It would execute the decryption algorithm and generate the required cookie. 

Within a week, both solutions were fully deployed. 

In total, over 7,500 websites continued receiving accurate monitoring without interruption. Not a single customer needed to change settings or contact their host.

Takeaways

Each individual site is a unique combination of plugins, themes, web hosts, owner, agency, admins, users, content, and so much more. A one-size-fits-all approach will falter from time to time. 

Therefore, the quality of a product is in how well it is able to adapt to shifting sands and these differing needs. And how much of that burden is passed onto customers. 

At WP Remote, our goal is to ensure site maintenance remains reliable and hassle-free. We take on 100% of that burden, always. 

Because in a world where the goalposts never stop moving, we, your technology partners, should handle the adjustments for you.