Made a status page tool, almost no configuration (a few environment variables), ready to drop in compose.yaml. If you run Podman but don't receive status alerts yet, try setting Yoself up, it should be relatively easy.

1. To monitor Podman, add volume /run/podman/podman.sock:/var/run/docker.sock. To check if an external website is up, add SERVER_EXAMPLE=https://example.org/.

2. To send alerts, set EMAIL_STATUS=admin@example.org and SMTP_{HOST,PORT,USER,PASSWORD}.

3. To generate a static page, set STATIC_HTML=/home/user/public_html/yoself.html. To only monitor containers and/or servers, but not host, set MONITOR_HOST=false.

Intended usage: One instance on each server whose containers you want to monitor. Another one (static page) on the server that checks if your main servers are up.

How it looks like: https://yoself.nykula.com/

Why?

I work with a few servers with Podman containers. Some containers have health checks defined in their Containerfile or my compose.yaml. Some don't include binaries neccessary to implement health checks; but to see if they work, it can be enough to query their HTTP API.

A server may experience load spikes and is sometimes close to running out of disk. Finally, a server may periodically become inaccessible because of network issues.

My goal is to get emails about server health events, with very little configuration per server. And to have an overview of what stands out, without deep insights (for detailed information, I'll ssh anyway). Ideally with one tool for it all.

The static page is needed because I only work part-time and don't have money to rent an extra VPS. For monitoring my main VPS, I use a shared system that lets users run apps in background and publish HTML pages.

Alternatives with similar features:

• Docker/Podman monitoring capability: Beszel, Simon, Uptime Kuma.
• Docker/Podman container auto-discovery: Beszel, Simon.
• Website monitoring: cState + monitorbot, Statping-ng, Uptime Kuma.
• Public, world-readable status page: cState, Uptime Kuma.
• Single container image: Simon, Uptime Kuma.
• Host usage monitoring: Beszel, Simon.
• Periodic refresh but not real-time: Uptime Kuma.
• Powered by Node.js: Uptime Kuma.
• Haven't researched yet, learned today: Gatus.

Non-goals, their features that Yoself doesn't have:

• Settings UI: Beszel, cState, Simon, Statping-ng, Uptime Kuma. (I want compose.yaml and/or .env to be the entire config, possible to keep in Git with version history.)
• Split monitoring and overview services: Beszel, cState + monitorbot.
• Large, detailed charts: Beszel, Simon. (Yoself is just two screens.)
• Private dashboard: Beszel, Simon. (Yoself is userless.)
• Key auth between servers: Beszel.
• Multi-user management: Beszel.
• Description of current incident. (If needed, I can make Yoself show recent RSS from Mastodon.)
• TCP, DNS, ping: cState + monitorbot, Uptime Kuma.
• Years of history: cState. (Yoself logs expire after 31 days.)
• Live metrics: Beszel, Simon. (Yoself periodically refreshes, but not every second.)
• Reading container journal on the web: Simon.
• File management: Simon.
• Telegram, Slack, Discord etc: Beszel, Simon, Uptime Kuma. (Plain text e-mail is enough for me.)
• Lightweight, written in compiled language: Beszel, cState, Simon, Statping-ng.
• Custom styling: Statping-ng.
• Regex matching of website responses: Statping-ng. (Yoself supports JMESPath.)
• Frontend using React or Vue: Beszel, Simon, Statping-ng, Uptime Kuma. (I use Preact with my SSR/ORM library EviKit, about which I wrote recently.)

Would be nice, but wasn't a strong need to implement yet:

• Weblate for continuous translation: Beszel, Uptime Kuma. (For Yoself, I edit Ukrainian .po using Poedit.)

Upd: re-read the rules and added [CBH] to title as per Rule 8. I didn't use LLMs when coding this project, as evidenced by my commit history on Codeberg. Developers of dependencies do use LLMs, though.