[FEATURE][API]: Expand /health API to include Database and Redis status checks

[PawelK2012]

🧭 Type of Feature

Please select the most appropriate category:

• Enhancement to existing functionality
• New feature or capability
• New MCP-compliant server
• New component or integration
• Developer tooling or test improvement
• Packaging, automation and deployment (ex: pypi, docker, quay.io, kubernetes, terraform)
• Other (please describe below)

🧭 Epic

Title: Expand health API
Goal: The /health API currently provides a basic health signal by validating Postgres connectivity and returning a generic healthy response. To improve observability and support more granular health monitoring, the endpoint should be expanded to include explicit status checks for additional infrastructure dependencies.
This change will enhance the /health response to report the health of both Postgres and Redis, while continuing to expose a clear overall service health indicator
Why now:

• SRE / DevOps teams gain clearer signals for monitoring and debugging
• Application developers can quickly identify dependency-related failures
• Platform and infrastructure tooling (e.g., health probes, dashboards) can make better decisions based on more granular health data
• This change improves reliability and observability without introducing breaking API behavior.

---

🧑🏻‍💻 User Story 1

**As a:**Platform engineer / SRE
I want: the /health endpoint to report the health of all critical infrastructure dependencies (Postgres and Redis)
So that: I can accurately determine service readiness, quickly diagnose failures, and integrate reliable health signals into monitoring and orchestration systems

✅ Acceptance Criteria

Scenario: All dependencies are healthy
  Given Postgres is reachable and responding successfully
    And Redis is enabled and reachable
  When the /health endpoint is called
  Then the response status field should be "healthy"
    And the response should include statusItems for both Database and Redis
    And both statusItems should have statusCode 200

Scenario: Redis is not enabled
  Given Postgres is reachable and responding successfully
    And Redis is disabled by configuration
  When the /health endpoint is called
  Then the response status field should be "healthy"
    And the Database statusItem should have statusCode 200
    And the Redis statusItem should have statusCode 503
    And the Redis statusItem message should indicate Redis is not enabled

Scenario: Postgres is unavailable
  Given Postgres is unreachable or returns a connection error
    And Redis is reachable
  When the /health endpoint is called
  Then the response status field should be "bad"
    And the Database statusItem should have statusCode 503
    And the Redis statusItem should have statusCode 200
    And the response should clearly indicate Postgres connectivity failure

Scenario: Health endpoint response format consistency
  Given any dependency health state
  When the /health endpoint is called
  Then the response should always include a top-level status field
    And the response should always include a statusItems array
    And each statusItem should contain name, statusCode, and message fields

📓 Additional Context

Response Examples

✅ Postgres and Redis healthy

{
  "status": "healthy",
  "statusItems": [
    {
      "name": "Database",
      "statusCode": 200,
      "message": "[POSTGRES]: Postgres Connection Successful"
    },
    {
      "name": "Redis",
      "statusCode": 200,
      "message": "ready"
    }
  ]
}

⚠️ Redis not enabled (service still healthy)

{
  "status": "healthy",
  "statusItems": [
    {
      "name": "Database",
      "statusCode": 200,
      "message": "[POSTGRES]: Postgres Connection Successful"
    },
    {
      "name": "Redis",
      "statusCode": 503,
      "message": "Redis is not enabled"
    }
  ]
}

❌ Postgres failure (service unhealthy)

{
  "status": "bad",
  "statusItems": [
    {
      "name": "Database",
      "statusCode": 503,
      "message": "Cannot connect to Postgres"
    },
    {
      "name": "Redis",
      "statusCode": 200,
      "message": "ready"
    }
  ]
}

[crivetimihai]

Thanks @PawelK2012. The DB health check already exists in the current /health endpoint (runs SELECT 1), so the main value-add here is the Redis health check and structured response schema. Key design consideration from the PR #3826 review: keep /health (liveness) lightweight and avoid adding Redis ping() to the liveness path — Redis slowness would cause pod restarts even when the app is healthy. Consider adding deeper dependency checks to /ready (readiness) or a new /health/detailed endpoint instead. See the review on PR #3826 for full details. Tagging as SHOULD for Release 1.1.0.