Lightweight Monitoring Endpoints for WordPress

The Goal

When monitoring a WordPress site, the endpoint should answer one simple question:

• Is the web stack reachable?

It should not load the full WordPress application unless you deliberately want an application-level health check.

That matters because many common WordPress URLs trigger PHP, database access, plugin loading, cron hooks, and background jobs. For a busy site, that turns a harmless uptime check into extra production load.

Best Lightweight Options

These are the best out-of-the-box choices when you want a low-overhead check and do not want to create a custom health endpoint yet.

1) /wp-includes/images/w-logo-blue.png

Why it is good:

• It is a core WordPress static file
• It is usually present
• It is served directly as a file
• It avoids loading WordPress, PHP, and MySQL

Example:

https://example.com/wp-includes/images/w-logo-blue.png

2) /wp-admin/images/spinner.gif

Why it is good:

• It is another core static file
• It is typically present on standard WordPress installs
• It is lightweight and predictable

Example:

https://example.com/wp-admin/images/spinner.gif

3) /favicon.ico

Why it is good:

• Very lightweight if it is a real file on disk
• Commonly used by monitors and browsers

Important caveat:

• Only use this if the site actually has a real favicon.ico
• If it does not exist, you may end up monitoring a 404, which is not useful

4) A known file under /wp-content/uploads/...

Why it is often the best real-world option:

• It is definitely a real file
• It is served statically
• It proves the web server and the site file storage are working

Example from Tekonline:

https://example.com/wp-content/uploads/2024/01/example-image-150x150.jpg

During diagnostics, this type of file returned essentially instantly compared with WordPress application URLs.

Endpoints to Avoid

These look convenient, but they are not lightweight:

• /
• /wp-load.php
• /wp-cron.php
• /wp-json/
• /wp-admin/...
• /wp-login.php
• /xmlrpc.php

Why to avoid them:

• They bootstrap WordPress
• They can trigger plugins and theme code
• They may touch the database
• They may trigger cron or background jobs
• They add avoidable load during frequent health checks

A Special Note About robots.txt

/robots.txt is only a good lightweight endpoint if it is a real static file on disk.

On many WordPress sites, robots.txt is virtual and generated through WordPress itself. In that case, it is not a lightweight monitoring target.

Best Choice in Practice

If you need a monitor right now and do not want to change the application:

• Use a known static file
• Prefer a file that already exists
• Prefer HEAD instead of GET if your monitoring system supports it

That gives you a cheap availability check without making WordPress do extra work.

Practical Recommendation

For a typical WordPress site, a good lightweight monitoring target is:

https://example.com/wp-content/uploads/2024/01/example-image-150x150.jpg

Why this is a strong choice:

• It already exists
• It is static
• It is fast
• It does not bootstrap WordPress

If you later want a better long-term setup, the next step is a dedicated /healthz.txt or /health.php endpoint. But without changing anything, a known static file is the safest option.