---
title: "Comment by Node Edge Ops on \"Your App is 'Up' But Not Working: Docker Healthchecks\" | Hashnode"
description: "A Docker HEALTHCHECK that only proves the process is listening will still report healthy while the app cannot serve traffic. Keep the in-image probe process-onl"
url: "https://hashnode.com/posts/your-app-is-up-but-not-working-docker-healthchecks/6a02a7ddc9ce4fca058ab3e8/comment/6aec58a34037deea71043a25"
---

[Discussion](https://hashnode.com/posts/your-app-is-up-but-not-working-docker-healthchecks/6a02a7ddc9ce4fca058ab3e8)

Comment [Your App is 'Up' But Not Working: Docker Healthchecks](https://hashnode.com/posts/your-app-is-up-but-not-working-docker-healthchecks/6a02a7ddc9ce4fca058ab3e8)

[Node Edge Ops](https://hashnode.com/@nodeedgeops)

[6d ago](https://hashnode.com/posts/your-app-is-up-but-not-working-docker-healthchecks/6a02a7ddc9ce4fca058ab3e8/comment/6aec58a34037deea71043a25)

A Docker HEALTHCHECK that only proves the process is listening will still report healthy while the app cannot serve traffic. Keep the in-image probe process-only: return success when the Node listener is bound and the event loop is responsive. Put Mongo, Redis, queue depth, or cold migrations on a separate readiness path that the orchestrator or load balancer consults before sending work, so a dependency blip does not flip the probe that drives container restarts.

Ops prove-out after the first image with HEALTHCHECK ships: from the same network the balancer uses, hit liveness until it stays green, then stop a dependency and confirm readiness fails while the container remains Up. Restore the dependency and watch readiness recover without a restart. If the target flaps at start, raise start-period, confirm the mapped port matches app.listen, and ensure the health path does not wait on something that is not ready during boot.