Short answer: for a Node.js app in Docker or Kubernetes, give startup, readiness, and liveness probes separate meanings, keep routine health traffic out of application logging, and measure state transitions instead of counting every successful check.
For a property-management API rolling out a new pricing rule, this preserves useful metrics: whether an instance can calculate rent correctly and accept traffic, without turning each kubelet poll into noise.
Which health signal should control each container decision?
Start with the decision, not the endpoint name.
Signal Question it answers Include Exclude Action Startup Has initialization completed?
Configuration parsing, pricing-rule compilation, required local warm-up Long-term dependency health Allow the process more time before other probes apply Readiness Can this instance safely receive a new pricing request now?
Ability to serve the active rule version and any required dependency state Optional analytics and background exports Remove the pod from Service endpoints Liveness Is the process stuck beyond local recovery?
Event-loop progress or another narrow process invariant Database, cache, and third-party availability Restart the container This split is the main noise filter.
A downstream dependency becoming unavailable can make a pod unready, but restarting the same healthy process usually doesn't repair that dependency.
If the dependency is placed in liveness anyway, every pod can restart together.
The health response has then amplified one problem into two: lost capacity plus a restart storm.
The pricing rollout makes readiness more demanding than “the port is open.” Imagine rule version is enabled for one building cohort.
A newly started instance has loaded configuration but hasn't compiled that version yet.
It is alive.
It isn't ready.
Its startup check should hold back liveness and readiness until initialization finishes; afterward, readiness should stay false until the active rule can be evaluated.
That distinction protects tenants from inconsistent quotes while keeping the process lifecycle understandable.
Don't put every dependency in every check.
When should startup, readiness, and liveness probes be picked?
Pick a startup probe when initialization can legitimately take longer than the liveness budget.
Kubernetes does not run liveness or readiness probes until the startup probe succeeds.
That makes startup the right place for one-time work such as loading and validating the pricing rules.
The catch is that an excessively generous startup window delays detection of a process that will never initialize, so derive the window from observed cold-start distributions rather than copying a large value.
Pick readiness for conditions that should stop new traffic but may recover without a process restart.
A pricing worker that temporarily lacks the active rule snapshot is a clean example: readiness failures remove the pod from matching Service endpoints while the container continues running, creating space for recovery and keeping the action proportional.
Pick liveness only for a condition a restart can fix.
An event loop that no longer advances qualifies; an unreachable billing database does not, because a fresh process reaches the same database.
This is a sharp trade-off — a narrow check can miss some degraded states, while a broad check can cause destructive restarts.
Favor the narrow invariant and alert on degradation through metrics.
Keep it narrow.
How should a beginner wire Kubernetes probes to a Node.js health endpoint?
Use distinct paths even if they share one small server.
The handlers below avoid network calls in liveness, return when startup or readiness has not been reached, and expose no tenant or property details. is enough for success because the kubelet needs status, not a diagnostic document.
The millisecond threshold is an example policy, not a universal Node.js limit.
I'm not sure what threshold fits your workload until its event-loop delay distribution is