New to the community? Start here

Uptime service repeats "appears down" – "is back online"

I changed the IP of my site today and it's now available via https. Since then I get mails DOWN alert, your site is back online, DOWN alert, your site is back online, DOWN alert, your site is back online, <repeat>

It appears like your service is not in sync. I write this in the hope that those mails stop soon and the service works correctly.

Fri, 20 Apr 2018 7:25:03
  • Predrag Dubajic
    • Support

    Hi Bernd,

    Hope you’re doing well today :slight_smile:

    The easiest thing that you can try for starters is to remove your site from the HUB and then connect it again and see if that will be enough.

    However, I believe that there’s something else causing this issue and it might be that your HTTPS is not configured properly.

    The thing is that I tested your site with a couple of site accessibility tools, like Uptrends and GeoPeeker, and I was getting some inconsistent results where your site was shown to be down from some locations, like Virginia, Palermo, Hamburg etc.

    I would suggest getting in touch with your host to see if everything is properly configured from their and if all the changes are properly propagated.

    Let us know how it goes.

    Best regards,

    Predrag

  • Bernd
    • Flash Drive

    Dear Predrag,

    it could of course be that DNS propagation needs some time which is why I wrote “It appears like your service is not in sync.” because some of your checks see the site back online.

    Take a look at:

    https://www.whatsmydns.net/#A/www.eidenschink.eu

    (185.26.156.72 is the correct one and is already nicely propagated)

    But as I am using your service via WPMUDEV Dashboard plugin it should be very easy for your tools to detect the correct IP anyway! Just a thought.

    Concerning the certificate: This would be a different problem if your uptime sensors fail under some circumstances with TLS extension SNI (server name indication). You might receive certificates with exactly the requested domain or multidomains (Cloudflare does this sometimes on their free plan). But only when TLS extension request fails you would see something like connection resets or default domains that don’t match the hostname.

    As some of your sensors sometimes say “is back online” I guess you have no TLS problem but a DNS propagation problem I can’t solve for you.

    Kind regards

    Bernd.

  • Adam
    • Support Gorilla

    Hello Bernd

    Thank you for your response.

    I checked the site again from outside.

    The DNS propagation (at least at this very moment) seems to be complete but if it wasn’t, that’s not something that could be corrected on our end. The way Uptime check works is that it pings your site every 2 minutes and if the response takes more than 30 seconds, it reports it as “down”.

    It takes the “home_url()” as an URL to ping (as it’s registered with The Hub – based on the same data). That’s why my colleague Predrag suggested removing the site from The Hub and adding it back – to make sure that registered URL is up to date. In general, The Hub would update it on its own but it doesn’t quite do it in “real time”. I’m not sure if you did that but so far, it looks like it’s still registered with no-SSL url. Furthermore, it seems that if you try to access site over HTTP there’s a “302 Moved Temporary” redirect so in that case, the URL in The Hub would not be automatically updated (“301 Moved Permanently” would cause update of the URL). Now, that in fact means that it doesn’t have much to do with TLS/SNI as this simply “doesn’t care” about that. No check is done on your site’s side – it’s performed externally, from external servers in the cloud.

    That gets me back to DNS and why that might be causing issues: if the propagation is not complete or it is but for some reason some routes to the site fail, the “ping” won’t reach the site (the same way it wouldn’t reach it if you’d issue “ping” command from console from your own computer).

    What I would do in that case, would be this:

    1. make sure that you site is actually set up for HTTPS, so when you go to “Settings -> General” page in site’s back-end both “WordPress Address (URL)” and “Site Address (URL)” are starting with https:// prefix

    2. get in touch with the host and ask them if they could check if these two IP’s are not being blocked in any way: 34.196.51.17, 52.57.5.20.

    3. once that’s done, remove the site from The Hub and add it back, like suggested by Predrag

    4. if you got any caches on site, clean them fully; if there’s any firewall on site – try temporarily (just for testing) disabling it

    5. once again double-check if DNS’es are showing still as fully propagated and enable the Uptime check back.

    If it still fails, let me know and I’ll get our sysadmins to see if they can find any additional information in logs on our end so we could “drill down” to the core of the problem.

    Kind regards,

    Adam

  • Bernd
    • Flash Drive

    Dear Adam,

    thank you very much for your in-depth response. I updated the “home” and “siteurl” options with wp-cli to indeed now https://.

    Interestingly enough when you use ‘home_url()’ it utilizes ‘is_ssl()’ under the hood which in turn detects the SSL state via the SERVER environment variable. So while this should satisfy many situations of course it will not fix mixed content situations or things might otherwise get tricky based on the scheme of the request.

    I also did as you said and dis- and reconnected the uptime monitor and we’ll see if that works out. No mail so far.

    Kind regards

    Bernd.