Your Site Returns 200 OK. That Doesn’t Mean It’s OK.

A monitoring system requests your home page. The server answers:

HTTP/2 200 OK
content-type: text/html; charset=UTF-8

The graph stays green. The uptime dashboard says 100%. Nobody gets
paged.

Meanwhile, scheduled tasks have not run for six hours, password-reset
email is failing, a plugin update replaced a file unexpectedly, the
upload directory is no longer writable, and a background queue is
growing faster than it can drain.

All of those failures can exist behind a perfectly healthy
200 OK.

The problem is not HTTP. The problem is what we ask HTTP to
prove.

HTTP health is request
health

A status code describes the result of a request. It does not certify
every subsystem that the application depends on.

For a simple static site, a successful request may be a useful
approximation of health. For WordPress, XenForo, WooCommerce, a custom
PHP application, or any system with asynchronous work, it is only one
signal.

A production application normally depends on several independent
paths:

• web requests;
• database reads and writes;
• scheduled jobs;
• email transport;
• filesystem permissions;
• uploads and temporary storage;
• background queues;
• DNS and TLS;
• third-party APIs and webhooks;
• caches;
• deployment artifacts.

A home-page probe often touches only a subset of those paths.

The first silent
failure: scheduled work

Scheduled work is a classic example because it is intentionally
separated from the page a visitor sees.

WordPress uses WP-Cron by default. A busy store may also use Action
Scheduler. XenForo add-ons and core functionality can rely on scheduled
entries. Custom PHP systems may have system cron, queue workers, or
timers.

If those jobs stop, the front end can remain available.

The symptoms appear elsewhere:

• scheduled posts remain pending;
• cleanup never runs;
• digests are not sent;
• feeds stop refreshing;
• expired records remain active;
• queues grow;
• recurring imports become stale.

The right question is not simply “does cron exist?” It is:

Is expected work progressing within a reasonable window?

That means checking timestamps, recurrence, backlog, callback
availability and, where possible, the age of the oldest pending
work.

A job that is five minutes late is not automatically broken.
Traffic-triggered schedulers naturally drift. But a job expected every
five minutes that has not progressed in two hours is evidence worth
investigating.

Mail can fail after
the page says success

Applications often report that an email was “sent” when what they
really know is that the message was handed to a transport layer.

Those are different statements.

A useful mail diagnostic separates at least these stages:

1. Application generated a message.
2. PHP or SMTP transport accepted it.
3. Remote mail infrastructure accepted it.
4. The message passed filtering and policy checks.
5. It reached the intended mailbox.

A successful call at stage two does not prove stage five.

That is why a deliberate test message is more useful than reading
configuration alone. It exercises the real transport path. Even then,
the result should be described carefully: “accepted by the configured
transport” is more precise than “email works.”

The filesystem can be
half-broken

A PHP application may read its own code perfectly while being unable
to write where it needs to.

Common examples include:

• an uploads directory that became read-only;
• an incorrect owner after a deployment;
• a full filesystem;
• a missing temporary directory;
• a backup location mounted read-only;
• a cache directory with stale permissions.

Again, the home page may render because reading code and templates
still works.

A useful filesystem check asks targeted questions:

• Does the expected path exist?
• Is it readable?
• Is it writable by the PHP process?
• Is there usable free space?
• Can a tiny test file be created, read and removed safely?

The final question is important. Configuration and permission bits
are indirect evidence. A controlled write/read/delete test verifies the
operation the application actually needs.

Database health is more
than “SELECT 1”

A database connection test proves very little by itself.

The application can connect while still carrying structural
problems:

• mixed character sets;
• unexpected table engines;
• missing indexes;
• missing primary keys;
• schema drift after an interrupted upgrade;
• very large tables whose growth changed operational assumptions;
• auto-increment values approaching a type limit.

None of these require the database server to be offline.

The safest first response is observation, not repair.

Useful read-only evidence includes:

SHOW TABLE STATUS;
SHOW CREATE TABLE some_table;
SHOW INDEX FROM some_table;

The exact queries vary by database and application, but the principle
is stable: understand the structure before changing it.

Running REPAIR, OPTIMIZE or
ALTER because a dashboard says “database issue” is not
diagnosis. It is mutation under uncertainty.

Modified files are
another silent class

A site can serve pages normally even after a file has changed
unexpectedly.

The change may be legitimate:

• an administrator edited it;
• a deployment replaced it;
• an add-on update changed the packaged file.

Or it may be accidental or hostile.

A cryptographic hash lets us ask a precise question:

Is this byte sequence identical to the expected byte sequence?

For SHA-256:

sha256sum package.zip

or on PowerShell:

Get-FileHash .\package.zip -Algorithm SHA256

A mismatch is evidence, not a verdict. It tells you the file differs.
You still need to determine why.

Redirects
can be technically successful and operationally bad

A redirect chain is another example of “working” behavior that can
still be unhealthy.

Consider:

http://example.com
  -> 301 https://example.com
  -> 301 https://www.example.com
  -> 302 https://www.example.com/en/
  -> 200

Every response is valid. The final page loads. But the route is
slower, harder to reason about and easier to break during future
configuration changes.

A loop can be worse: two systems can disagree about canonical host or
scheme and redirect the request forever.

A health model should therefore distinguish availability from
correctness and efficiency.

What a better health
model looks like

Do not replace uptime checks. Add layers around them.

A practical model can be divided into five questions:

1. Can users reach the
application?

Check DNS, TLS, HTTP and key public routes.

2. Can the application
use its dependencies?

Check database connectivity, filesystem paths, temporary storage and
mail transport.

3. Is background work
progressing?

Inspect cron, queues, scheduled actions and timestamps.

4. Does
the installation still match its expected state?

Check file hashes, versions, required extensions, schema
characteristics and configuration boundaries.

5. Are important
workflows actually completing?

Use deliberate tests where safe: send a test email, perform a tiny
upload test, verify a redirect, or compare a release checksum.

Read-only diagnostics are
underrated

There is a strong temptation to combine detection and repair into one
button.

That can be convenient, but it also increases the blast radius of a
wrong diagnosis.

For production systems, a useful default is:

Detect. Explain. Then let a human decide whether a change is
justified.

A diagnostic tool should be comfortable saying:

• “This is late, not necessarily broken.”
• “This file differs; the reason is unknown.”
• “The transport accepted the message; mailbox delivery is not
  proven.”
• “This table is unusual; no repair was attempted.”

Precision creates trust.

A practical weekly check

For a modest WordPress or XenForo installation, a short operational
review can catch a surprising number of failures:

1. Confirm important public routes return expected responses.
2. Check scheduled work for overdue or stalled entries.
3. Send one deliberate mail test.
4. Confirm writable application paths.
5. Review database engine, charset and capacity signals.
6. Verify packaged file integrity where manifests exist.
7. Trace important redirects.
8. Confirm the current production ZIP or release artifact matches its
   published checksum.

This is not glamorous observability. It is basic evidence
gathering.

And that is the point.

A green home-page probe is useful. It is simply not a certificate
that the rest of the system is healthy.

200 OK means the request was OK.

Your application still has to prove everything else.