So recently been spending time configuring my selfhosted services with notifications usint ntfy. I’ve added ntfy to report status on containers and my system using Beszel. However, only 12 out of my 44 containers seem to have healthcheck “enabled” or built in as a feature. So im now wondering what is considered best practice for monitoring the uptime/health of my containers. I am already using uptimekuma, with the “docker container” option for each of my containers i deem necessary to monitor, i do not monitor all 44 of them 😅
So I’m left with these questions;
- How do you notify yourself about the status of a container?
- Is there a “quick” way to know if a container has healthcheck as a feature.
- Does healthcheck feature simply depend on the developer of each app, or the person building the container?
- Is it better to simply monitor the http(s) request to each service? (I believe this in my case would make Caddy a single point of failure for this kind of monitor).
Thanks for any input!
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.
Better late than never! Thanks for the tips aswell as your project, looks rather interesting 😊 Ill have to test deploy this when i get home!