Hi Gelu,
For this case, I would recommend using an external uptime monitor as the primary solution.
A Supervisor event listener like httpok can help restart an application process when Supervisor itself is running, but it cannot help if supervisord is down or if supervisorctl can no longer talk to the Supervisor socket. Likewise, a local cron watchdog can work, but it also adds another moving part and can create problems like duplicate supervisord instances if the config/socket paths are not handled very carefully.
The safer approach is to monitor the public HTTP endpoints from outside the VPS using a service such as UptimeRobot, Better Stack, Cronitor, Healthchecks.io, Pingdom, etc. That way you get notified even if Supervisor, the VPS networking, or local mail delivery is broken.
If you do continue using Supervisor locally, the main thing is to keep the setup simple:
- use one explicit supervisord.conf path everywhere
- do not use /tmp for the Supervisor socket
- keep the socket, pidfile, and logs under your home directory
- do not start supervisord blindly from cron unless you are also checking that an existing instance is not already running
But I would treat that as a customer-managed recovery script, not the main monitoring layer.
For notifications from the VPS, you should not need to run a full mail server just for occasional alerts. Opalstack provides sendmail support for outgoing mail, so scripts can use that where appropriate. However, for outage alerts specifically, external monitoring is still preferable because local notifications may fail during the same type of outage you are trying to detect.
So the short version is: use external uptime monitoring for alerts, optionally use Supervisor/httpok for app-level recovery, and avoid relying on a local watchdog as your only safety net.
You could provision a Value Shared plan and run the watchdog script there, and use the diskspace for backups, etc. OR the disk space would go to your mail quota so its not wasted.
