CE Phoenix Cart Forum

• Zero site slowdown: It checks your store in milliseconds in the background without loading full web pages.
• No false alarms: It verifies a failure twice before alerting you, so temporary hosting hiccups won't spam you.
• Simple set-up: You just paste your Slack link into your shop Admin and click "Enable".

I think the idea is workable. The health endpoint does not need to report every possible failure itself. The central monitor can infer the failing layer from the response.

For example:

* No HTTPS connection: server, DNS, network or hosting problem.
* HTTP 500/502/503: web server, PHP-FPM or application problem.
* HTTP 200 but no valid JSON: PHP or application output problem.
* Valid JSON with database down: PHP works, but MySQL does not.
* Valid JSON with everything up: web server, PHP and MySQL are responding.

So if PHP is completely down, `health.php` cannot return `"php": "down"`. That is expected. The fact that the monitor receives no valid health response is itself the PHP/application failure signal.

I would keep `health.php` extremely small and avoid loading the complete Phoenix `application_top.php`, because that loads sessions, configuration, language files, hooks and other shop functionality. The health check should ideally perform only:

1. A basic PHP response.
2. A database connection with a very short timeout.
3. A simple `SELECT 1`.
4. A small JSON response.

Something like:

```json
{
"status": "up",
"database": "up",
"timestamp": "2026-08-02T12:00:00Z"
}
```

If the database test fails, it could return HTTP 503:

```json
{
"status": "degraded",
"database": "down",
"timestamp": "2026-08-02T12:00:00Z"
}
```

I would not expose PHP versions, MySQL versions, file paths or actual error messages. A public health endpoint should reveal as little technical information as possible.

I would also protect it with a unique revocable token, preferably sent in a request header rather than using a predictable public `/health.php` URL.

It may also be worth monitoring the actual storefront separately. A database can be reachable and the health endpoint can pass while the homepage still produces a fatal error. The system could therefore have three checks:

* HTTPS/server availability.
* PHP and database health endpoint.
* Storefront content check for a known marker.

Two consecutive failures before sending an alert makes sense, followed by a separate recovery notification when the shop is reachable again.

The largest concern for me would not be whether it is technically possible, but security, privacy and operational responsibility. Once phoenixcart.org becomes the central monitor, it must itself be highly available and securely store shop URLs and notification credentials. Slack webhook URLs in particular should probably remain inside the shop or be encrypted, rather than being stored as plain text by the monitoring service.

Dan Cole wrote: ↑Sun Aug 02, 2026 2:40 pm FWIW, years ago I used an outside service that would periodically test my site and report whether it was down and out. I can't recall the name of the service and it wasn't instance....it would query the site every 5 or 10 minutes or so and send an email whenever there was a failure.