Uptime Monitoring

WordPress is easy to use. Behind the scene, it is a complex piece of software, running on PHP and MySQL. Monitoring the uptime of WordPress sites may seem straightforward. But, in reality, it is easy to miss the downtime using conventional methods.

Let me provide you with an example. Let’s take this site… tinywp.in . I monitor this site using multiple uptime monitoring services. They keep watching the home page at https://www.tinywp.in and see if it shows any errors. They notify me in case of the following errors

  • 500 Internal Server Error
  • 502 Bad gateway
  • 504 Gateway timeout

Basically, uptime monitoring services notify me of any 5xx errors. We may also configure them to notify upon 4xx errors such as 404 (Not Found Error). Usually, it is not necessary to notify upon 3xx status codes (related to redirection).

Everything looks good for a normal site, include a WordPress site. But, there are occasions, the normal monitoring wouldn’t be enough.

White Screen of Death

There are multiple occasions when a site goes down with white screen of death, but the monitoring services fail to notify me. This is because the site returns 200 (Success) message. In most such occasions, the site would actually send some content to the browser, but not enough to display something useful. It means the site sends back partial content.

How do we solve this?! Most monitoring platforms offer the ability to fetch the actual page and look for a particular word or text in it. We do not want to search for the title of the site, as it appears in multiple areas. The good practice is to look for a word or text that appears at the bottom of the site, such as the footer information. Copyright information is probably the best text to search for.

Full-page Caching

Most sites use some sort of caching, including full-page caching. The notable exceptions are e-commerce sites or any site where we have tons of logged-in users (such as a forum). For a blog, where we have a series of articles, having a full-page caching layer has come a standard practice. There are multiple full-page caching solutions are available, such as WP Super Cache, WP Rocket cache (paid product, though). Irrespective of the actual full-page caching layer a site uses, they all basically cache the home page and articles in a site. There are some caching solutions keeps the cache outside of PHP, such as Varnish (in memory) or WP Super Cache (in disk). So, even if PHP / MySQL goes down, the cached content is fetched from disk or memory and is served to the visitors.

It looks great. However, please read the last line in the previous paragraph. When PHP / MySQL goes down, the visitors would not be aware of it. So does a uptime monitoring service. So, the best practice is the monitor the uptime of a page that actually involves PHP and / or MySQL without any caching layer in the middle. Can you guess what it is?

There are multiple pages where WordPress requires PHP and MySQL. One such page is the login URL such as https://example.com/wp-login.php . So, when we instruct our monitoring services to monitor the login URL of our site, we will be notified of any downtime in PHP / MySQL (even though the front-end of the site is still being served from cache for other visitors). Be sure to utilize the word search functionality in your uptime monitoring service, if it is supported. Normally, we can search for the text “Lost your password?” that appears just below the login button.

Conclusion

In reality, the uptime monitoring can become more complex. For example, if we use a proxy such as Incapsula or Cloudflare that offers “always-on” technology (albeit only for a limited number of pages), we may never know if other parts of the pages are inaccessible. So, it is recommended to actually monitor a random page (that changes every day or hour). In addition, we can create our own little page to detect if it is only PHP or MySQL is down. We still need to consider these edge cases, if we are dealing with a mission-critical website.

We may even consider monitoring the performance of the site. At times, both the front-end and back-end may be up. But, both or one of them may be slow (too slow compared to a normal day). As a result, we would be losing visitors, losing the search engine rankings, etc.

To start with, I’d suggest to monitor both the front-end of the site (such as home page) and the back-end of the site (such as the login URL). In this way, we would know when the site goes down for logged-in users and normal visitors.

Happy blogging!

Sandboxing email for a local WP site using just three lines of code!

In a local-staging-live workflow, often we have some restrictions on both local and staging / development environments. A common restriction is to disallow indexing of the development site that may introduce duplicate content in the search result, if indexing is allowed (that is not uncommon when we set up the live site and then copy it to develop further :-) ). There are lot more restrictions and workarounds in order to setup a perfect development or local environment. Here, let me share a particular solution regarding emails. Let me start with some of the use cases.

Continue reading “Sandboxing email for a local WP site using just three lines of code!”

Script: WordPress in a (LEMP) box!

There are plenty of scripts in the internet, some of them even open source, that helps us to install WordPress automatically in a (single) server. Bitnami is the most popular among them. However, none of them met my requirements. I have some design considerations, security requirements and performance checklists. Since none of the existing tools met all my principles, I started developing my own tool to set up a (single) WordPress site in a (tiny) server.

Continue reading “Script: WordPress in a (LEMP) box!”

Is Your Awesome Site Mobile Friendly Too?

Image - mobile friendly sitesToday is the day when Google has started implementing mobile friendliness as a search engine ranking factor. The actual announcement in this regard was done two months ago in the official WebMasterCentral blog. It also started showing a tiny warning in the official blog since then. If you use WordPress and if your site is not mobile friendly, yet, there are options to convert it (for free) to fit into mobiles nicely.

Continue reading “Is Your Awesome Site Mobile Friendly Too?”

W3 Total Cache configuration for Nginx-Apache server stack

During the past 24 hours, there were two people had the following situation and were looking for a solution. Their use-case is…

I’m currently using a Nginx frontend / Apache backend setup. The W3 Total Cache plugin detects Apache and will only show me the Apache rewrite rules.

Here’s another quote from the other person who was looking for a similar solution…

The nginx.conf file does not exist. W3 Total Cache plugin detects that Apache is running – thus gives me the rewrites for that webserver instead. I am using Nignx in front of Apache – not a Nginx/PHP-FPM solution

Interesting, but not uncommon. So, I dived in and modified my existing Nginx rules for WP Super Cache plugin and provided a unique solution. Continue reading “W3 Total Cache configuration for Nginx-Apache server stack”

W3 Total Cache 1.0? – Sneak Peek!

Banner of W3 Total Cache pluginUpdate (Feb 5, 2013): The beta version that I tested, has been released as version 0.9.2.6 with more features than mentioned below. So, this post is void as of February 5, 2013 (in less than 2 weeks of publishing it). :(-

W3 Total Cache is back in active development, nearly after a year. I’m one of the lucky people who got the opportunity to test the beta version of the upcoming release, probably 1.0.0.0! It brings a few new features, including a more-intuitive troubleshooter. Continue reading “W3 Total Cache 1.0? – Sneak Peek!”