Near Instant Alerts if your shop goes down (Would you use this?)

[burt]

uc.jpg

--

The Problem

A server hiccup, hosting issue, or database error quietly takes your store offline, and you don’t find out until a customer emails you hours later. Every minute your store is down without you knowing is a lost sale.

The Proposed Solution

A super simple, automated alert system for Phoenix Cart:

1. You drop one tiny file into your store’s root folder.
2. A central monitor (hosted here at phoenixcart.org) pings that file every few minutes to check that both your web server and database are healthy. There could even be the possibility of a decentralized monitor - worth exploring.
3. Instant Slack Alert (or email - aware that the email would need to be different to your shop domain!) if your shop goes down, you automatically get an instant message so you can fix it right away.

---

Why this approach?

• 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".

---

Would you use this?

I want to see if this is something shop owners would actually use. If there’s enough interest, I'll look into flowcharting, then maybe we can look at making something together just as we did with Product Anywhere.

This system will be a bit complicated codewise, as it needs to be really easy for the end shopowner.

Please post your thoughts/ideas.
Open to any idea or critics, be as harsh as you like.

If you have little to no interest, please say so ! Even that helps...

If anything doesn't make sense, ask questions. Your questions might spark ideas, and I'll do my best to answer..

[burt]

FAQ - will update if thread evolves

Why Slack
Because it's instant, and I think most shopowners have (a) a mobile phone and (b) I -think- (I might be wrong) have it close at all times even when asleep. Email is just as good to get a notice, but email could be missed if not within working hours.

Your Privacy
phoenixcart.org would store just two things, both of which shopowner would give;
a/ the URL to your shops /health.php
b/ contact method [email, slack, etc, even possibly SMS alert in the future]
It would then also store your shops UP/DOWN status as well, to allow a notice to go to your contact method.

[tessthepup]

What a brilliant idea which will enhance Phoenix immeasurably.

I had a site go down recently because the domain had expired. I do not even remember seeing the email and to be honest never login to the registrar unless I need to update DNS or purchase a new domain.

[ArtcoInc]

@burt Does this use a Ping, or a HTTP Status Code?

M

[burt]

I haven't sketched out mechanics/logistics at all.
This thread is for ideas to help illuminate the way forward.

The general idea is your phoenix hosts a "health" page which returns some JSON details.

{
"http": "200",
"php": "up",
"mysql": "down"
}

If any of those details return "something wrong" when phoenixcart(org) checks, you get a message.

--

I'm not sure that what I envisage is even workable.
IE, if your MySQL is down, this "health" page would not load. Ditto for php being down.

Can anyone see a solution?

[azpro]

Could be a nice addonn - but at the same time .. I didn't experience much downtime the past 25 years - accept for bigger network (eg DNS) failures - or small hick-ups because of my own development errors. But still it might be helpfull.

I have asked ChatGPT's opinion:

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.

Hope this helps ..

[Dan Cole]

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 instant....it would query the site every 5 or 10 minutes or so and send an email whenever there was a failure.

Dan

[ArtcoInc]

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.

Google offers this as a "free" service. Tests the site every 5 minutes. I've been using it on one of my shops for years.

(it has also pointed out just how poor my host is ... but, I've been just too lazy to move to another host (yet))

M

[burt]

Thanks Dan, Malcolm - I also used an outside system but it was a long time ago. It definitely wasn't Google - didn't even know they offer a solution!

I am quite enthused by this idea but the more I think about it the less I am, it's quite a lot of hurdles to negotiate.

TY @ all. And to @azpro for the deep dive on the tech complexity. It's something that could be interesting if we could make it work as a community project, as we did with PA?

The other way I was thinking, rather than phoenixcart.org being the center, would be to somehow decentralize it, so one shop checks uptime for `x` other shops. who each check uptime for `x` other shops etc and so on. But that made my brain hurt and I soon dropped that idea. That's not to say that it would be impossible though, it just needs a lot of thinking about.

Long story short;

I'm looking for ways to give value to shopowners at zero cost, outside of the realm of the "shop" software (if that makes sense).

[Kofod95]

I like the idea behind. Offer some kind of service/benefit beyond the actual cart - something shopowners don't check themselves very often, maybe?
What would new store owners worry about, when choosing Phoenix instead of Shopify or even other OS carts? Are there things we could do to ease that worry?
These are open questions.

From experience I can say, that we have experienced customers asking why they don't receive e-mails suddenly. We rarely send emails to ourselves from our shops. Could the same idea be used to trigger weekly emails, sending an alert to a store, if emails don't come one week? Or maybe a security-check-type module, that sends a copy of the auto-generated emails to the store owners, for them to check that it still works, and evaluate the look and content? Just thoughts and ideas.

//Daniel