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!
