One thing that helps with the “should I update?” anxiety: knowing what changed and whether it actually matters for your setup before pulling the trigger.

I built Maintenant (GitHub) and one of the features I added for exactly this reason is update detection — it checks OCI registries via HEAD requests (no image pulls, no bandwidth waste) and tells you which containers have newer images available. The Pro tier goes further with CVE detection and risk scoring that cross-references whether the container is exposed to the internet, has dependents, etc.

It won’t auto-update anything — that’s a deliberate choice, the tool is observe-only and never touches your stack. But it gives you the information to decide when updating is worth the risk, instead of either blindly auto-updating with Watchtower or manually checking Docker Hub every week.

Also does container monitoring, HTTP/TCP checks, heartbeats for cron jobs, and SSL cert tracking if you want to consolidate. Single container, zero config, ~17 MB RAM. AGPL-3.0.

Solid starting point. One gap I’d flag: you have Portainer for management and Watchtower for updates, but nothing that tells you when something actually breaks. When you’re running this many containers, you’ll eventually wake up to a service that silently crashed at 3am.

Two directions depending on how deep you want to go:

• Minimal: Uptime Kuma — great for HTTP pinging your services. Simple, clean UI.
• Docker-native: Maintenant (GitHub) — single container, auto-discovers everything via the Docker socket, tracks container states + restart loops + HTTP endpoints + cron jobs + SSL certs. No config needed, ~17 MB RAM, read-only socket access.

Disclaimer: I built Maintenant, so I’m biased — but the reason I built it is exactly this gap. Portainer tells you what’s running, Watchtower keeps it updated, but neither alerts you when something is unhealthy. Worth adding monitoring before you need it.

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.