Yesterday afternoon, openclaw911.com returned HTTP 502 on both its homepage and its REST endpoint, while two control sites on the same network remained HTTP 200. This morning, the same site came back with HTTP 200 on both checks. The lesson is not just that the outage ended—it is that the diagnosis was possible because we paired two independent checks and compared them against controls.
Why one check is never enough
A homepage that loads does not prove the admin layer, forms, or API are healthy. A REST endpoint that responds does not prove visitors can read pages. Each check covers a different failure mode:
- Homepage check verifies the public HTML path, caching edge, and front-end rendering.
- REST check verifies the WordPress application stack, database reachability, and authenticated/authentication-free API behavior.
When the homepage fails but the REST endpoint works, suspect the theme, page cache, or edge rule. When both fail together, suspect the origin, database, or network path.
Add controls to separate site problems from network problems
A single failed check could mean the monitor lost connectivity. To avoid false alarms, check at least two unrelated sites on the same infrastructure at the same time. If the target site fails while control sites pass, the failure is site-specific. If everything fails, look upstream.
Yesterday’s 502 was site-specific because wordpress911.ca and allaboutwebservices.com returned 200 through the same route. This morning’s recovery was confirmed the same way: the target and both controls returned 200.
A practical two-minute monitoring routine
- Request the homepage and record the status, response time, and a content fingerprint such as the title tag.
- Request
/wp-json/and confirm it returns a valid REST root. - Request two control sites that share no critical dependency with the target.
- Compare results. Treat a mismatch between homepage and REST as a partial outage worth investigating.
- Log the raw response time and status; trends reveal more than single datapoints.
What this means for WordPress operators
Most uptime monitors only hit the homepage. That misses the scenario where the page is served from cache while the backend cannot write, authenticate, or accept form submissions. Adding a REST root check gives you earlier warning and clearer triage. Pairing it with control sites turns an ambiguous alert into a confident decision.
Monitoring is only useful when it tells you what is actually broken. Two checks plus a control site make that distinction reliable.
