Late to the party but your questions are good ones, so here goes:

1 - Notifications: The real issue isn’t notification plumbing (ntfy/Gotify/whatever) — it’s that most monitoring tools force you to choose between container-level awareness and service-level probing. You end up gluing Beszel (resources) + Uptime Kuma (HTTP) + something else (cron jobs) together.

2-3 - Healthcheck availability: It’s entirely up to whoever builds the image. You can check with docker inspect --format=‘{{json .State.Health}}’ <name> but as you found, most images don’t bother. The good news: you don’t actually need built-in healthchecks to know if a container is healthy. Tracking state transitions (running → restarting → exited), restart counts, and exit codes already tells you a lot — and any tool that watches the Docker socket can do that without the container having HEALTHCHECK in its Dockerfile.

4 - HTTP vs container monitoring: Both. HTTP tells you the service works end-to-end. Container state tells you why it doesn’t (crashed, OOM, restart loop). Monitoring only HTTP through Caddy means you miss backend containers that aren’t web-facing (databases, workers, queues).

Full disclosure, I’m the dev — but since you’re describing exactly the problem I built it to solve: Maintenant is a single container that auto-discovers everything on your Docker socket (all 44 containers, zero config), tracks states/healthchecks/restart loops, and also does HTTP/TCP endpoint monitoring + heartbeat URLs for cron jobs + SSL cert tracking. Basically consolidates the Uptime Kuma + Healthchecks-io + container awareness gap into one tool. ~17 MB RAM, read-only socket, AGPL-3.0. Won’t replace Beszel for detailed resource metrics, but it fills the monitoring gap you’re describing.