My container says running. Do I still need monitoring?

Yes, because running only means the process exists. The application inside can be frozen, cut off from its database or returning 500 to every request while Docker cheerfully reports the container as running.

What if my image has no HEALTHCHECK defined?

AgentWatch still works. Without the HEALTHCHECK layer you keep the other two: configure an HTTP probe so the agent calls your app health endpoint on localhost, and the agent always tracks container state and restart count regardless.

How does the agent read container data, and is that safe?

The agent reads the Docker socket on its own machine and collects metadata only: name, image, state, restart count and health result. It does not read logs, does not touch data inside containers and never executes commands in them.

Can the HTTP probe reach services outside my server?

No. The probe only accepts localhost or 127.0.0.1 and refuses to follow redirects; any other host is rejected. That design makes it impossible to abuse the probe for scanning your internal network.

Will a crash-looping container be detected?

Yes. The agent reports the restart count of each container, so a crash-restart loop, which the running state normally hides, shows up clearly on the dashboard instead of silently repeating all night.

Docker container monitoring done right

Docker has a favorite answer to “how is the container doing”: running. The problem is that running only means the process exists. The application inside may be frozen, disconnected from its database, or serving errors to every single user. Real container monitoring has to look deeper than one status word.

Why does “running” not mean healthy?

Because the Docker state describes the process, not the application. A few scenarios familiar to anyone who has operated Docker long enough:

A Java app exhausts its heap and hangs solid, but the process never dies. Docker: running.
A web container loses its database connection and every request returns 500. Docker: running.
A container crashes and the restart policy props it back up every 5 minutes, so users hit intermittent errors all day. Docker: running, with a restart counter climbing that nobody watches.

To know the truth you need several signal sources and an honest way to merge them. That is exactly the three-layer design in AgentWatch.

What are the three health layers?

The agent on your server evaluates every container through three layers. A bad signal on any layer flows straight into the combined state:

Layer	Signal source	Question it answers
1. Docker HEALTHCHECK	The health command declared by the image, run periodically by Docker	Does the app consider itself healthy?
2. Internal HTTP probe	The agent calls the app health endpoint on localhost	Does the app actually answer requests?
3. Process status	Container state and restart count from Docker	Is the process alive, and is it crash-looping?

The layers cover each other’s gaps. HEALTHCHECK sees deepest but not every image declares one. The HTTP probe confirms the app genuinely responds, configured by you when the app exposes a health endpoint. Process status is available for every container with zero preparation. Everything merges into one state on the dashboard: healthy, degraded or dead, tagged with which layer said so.

How does the agent read container data?

The AgentWatch agent is a single Go binary running on your server. It reads the local Docker socket and reports over HTTPS every 30 seconds. For containers it collects metadata only: name, image, state, restart count and health result.

What the agent does not do matters just as much: it does not read container logs, does not read data or environment variables inside containers, never executes commands in them and accepts no remote control. The internal HTTP probe may only call localhost and never follows redirects. The full behavior, the exact files installed and the clean removal steps are documented on the agent page.

What happens when a container goes unhealthy?

When a container’s combined state degrades, AgentWatch opens an incident and alerts the channel you chose, Zalo or email, naming the container, the server and the layer that raised the flag. When the container recovers, the incident closes itself with a recovery message and the duration.

That rewrites the familiar midnight script. Instead of spending the morning digging through logs to guess when a container died, the timeline is waiting for you: unhealthy at 01:42, recovered at 01:47, restarts up from 3 to 7. Your job becomes fixing the cause, not reconstructing the crime scene.

What do you need to prepare?

Almost nothing, because layer 3 works for every container the moment the agent runs:

Create an AgentWatch account and add a server in agent mode.
Run the one-line install command. The agent detects Docker on its own and starts reporting the container list.
If your app has a health endpoint, configure an internal HTTP probe to enable layer 2. If the image declares a HEALTHCHECK, layer 1 is picked up automatically.

Adding a HEALTHCHECK to your images is a small investment worth making: one line in a Dockerfile in exchange for a health signal from inside the application itself.

What does Docker monitoring cost?

Container monitoring is part of the agent, so pricing follows the number of servers with the agent installed, not the number of containers. The Free plan covers 2 servers. Paid plans start at 49,000 VND per month for 5 servers, Team at 149,000 VND for 15 and Business at 399,000 VND for 50, with check interval and history retention scaling alongside. See the full breakdown on the pricing table or start from the homepage.

During the beta, new accounts get the Business plan free. If your infrastructure runs on Docker, these three health layers are the difference between “probably fine” and knowing it is fine.

Docker container monitoring: three health layers instead of one word, "running"