{
  "id": 3146670,
  "title": "App Health Endpoint Design: 3 Probes That Keep Logging and Metrics Useful",
  "url": "https://urgent.news/2026/08/25/app-health-endpoint-design-3-probes-that-keep-logging-and-metrics",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-25T00:02:49.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/evanshepherd5623/app-health-endpoint-design-3-probes-that-keep-logging-and-metrics-useful-50ld"
  },
  "original_language": "en",
  "account": "When crafting health probes for a Node.js application running in Docker or Kubernetes, it is crucial to differentiate their meanings and purpose. Startup probes determine if initialization is complete, readiness probes assess whether the instance can safely receive new requests, while liveness probes evaluate if the process is stuck beyond local recovery. Routine health checks should be excluded from application logging to prevent log noise.\n\nFor a property management API rolling out a new pricing rule, useful metrics can be preserved by measuring state transitions instead of counting every successful check. This distinction ensures that an instance can calculate rent correctly and accept traffic, without turning each kubelet poll into unnecessary noise.\n\nWhen selecting which health signal controls each container decision, start with the decision, not the endpoint name. The signal should answer the following question: What should control the container decision? For example, if the focus is on whether initialization has completed, implement a startup probe. If the focus is on whether the instance can safely receive a new pricing request, implement a readiness probe. If the focus is on detecting if the process is stuck, implement a liveness probe.\n\nEach container decision should be guided by the appropriate health signal. The startup probe determines if initialization has completed, allowing the process more time before applying other probes. The readiness probe checks if the instance can safely receive a new pricing request, removing the pod from Service endpoints if not ready. The liveness probe checks if the process is stuck beyond local recovery, restarting the container if needed.\n\nThis split is essential for filtering out noise. A downstream dependency becoming unavailable can make a pod unready, but restarting the same healthy process may not repair that dependency. If the dependency is placed in liveness instead, every pod can restart together, amplifying the problem. By keeping the health response narrow and focused on the specific condition, lost capacity and restart storms can be avoided.\n\nWhen implementing Kubernetes probes for a beginner Node.js health endpoint, it is recommended to use distinct paths even if they share one small server. The handlers should avoid network calls in liveness, return a 503 status when startup or readiness has not been reached, and expose no tenant or property details. A status of 204 is sufficient for success, as the kubelet only needs status information, not a diagnostic document.\n\nIn the provided code snippet, the healthServer listens for GET requests on three specific URLs: /health/startup, /health/ready, and /health/live. The startup probe checks if initialization has completed, returning a 204 status if true and a 503 status if not. The readiness probe verifies if the instance can safely receive a new pricing request, considering the active rule version and dependency state. If not ready, it returns a 503 status. The liveness probe evaluates the event loop's responsiveness, returning a 204 status if responsive and a 503 status otherwise. This approach ensures that each probe serves its intended purpose, keeping the application healthy and responsive while minimizing unnecessary noise and restarts.",
  "summary": "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…",
  "key_points": [
    "Startup probe checks initialization completion",
    "Readiness probe assesses safe request handling",
    "Liveness probe detects process stuck state"
  ],
  "editors_take": "Differentiating health probes by purpose, such as startup, readiness, and liveness, helps Node.js applications in Docker or Kubernetes maintain useful logging and metrics by avoiding unnecessary noise and restarts.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}