1. Know what restart policies and HEALTHCHECK do not cover
restart: unless-stopped brings a crashed container back; a HEALTHCHECK directive lets Docker mark it unhealthy. Both are recovery mechanisms, not monitoring: neither tells a human anything, and both run on the host itself, so the failures that take the whole host down (kernel panic, disk full, network loss, the Docker daemon dying) take them down too. The only vantage that survives every host-level failure is one that does not run on the host.
2. Add an outside check per exposed service
Each container that publishes a port gets its own check: HTTP for web services, TCP (with optional TLS and certificate-expiry tracking) for databases, brokers, and everything else. Checks run from RealUptime's cloud probe regions on your chosen interval, each region reporting separately, and alert through email, Slack, webhook, or your paging tool when a failure is confirmed.
3. Run the agent for the inside numbers
Add the agent as one more service in your Compose file, one environment variable and done. It reports the host's CPU, memory, disk, and load, and on agents from version 0.2 the other containers on the same host from cgroup v2, without a second agent per container. That is how "one container is eating all the memory" becomes visible before it becomes "everything on the box is slow". It reads resource usage only: no container logs, no environment variables, no inbound port.
4. Give request-less containers a heartbeat
A queue worker or a scheduled one-shot container exposes no port, so there is nothing to probe. Create a heartbeat monitor for each: the container pings its unique URL on a loop or at the end of each successful run, and pings stopping is what fires the alert. That catches the worker that exited quietly and the cron container that never started, both invisible from outside otherwise.
5. Put it all on one status page
Add the host component and each service check to a status page, so "the host is fine, one container is down" and "the host itself is in trouble" read as the different incidents they are, to your team and your users alike, from the same measurements that page you.
Go deeper
The full reference lives in the docs: Docker monitoring documentation. Error codes named above are each explained in the error-code reference.