Skip to main content

​
Overview

Health check endpoints provide visibility into system status and service dependencies. These endpoints are used by load balancers, orchestrators (Kubernetes), and monitoring tools to determine service readiness and liveness.

​
GET /health

Comprehensive health check covering all system dependencies.

​
Request

curl http://localhost:3000/health

​
Response

​
status
string
required
Overall system health status: healthy, degraded, or unhealthy
​
timestamp
string
required
ISO 8601 timestamp when the health check was performed
​
version
string
Application version from APP_VERSION environment variable
​
uptime
string
required
Service uptime duration (e.g., 2h15m30s)
​
services
object
required
Health status of individual services
​
cache_metrics
object
Detailed cache performance metrics (optional)
​
cache_stats
object
Cache hit/miss statistics by category (optional)

​
Response Codes

  • 200 OK: Service is healthy or degraded (non-critical services unavailable)
  • 503 Service Unavailable: Critical services (database) are unhealthy
The /health endpoint returns 503 only when critical services like the database are down. Non-critical service failures (CCXT, Telegram) result in a degraded status with 200 OK, allowing the service to remain available for read-only operations.

​
Example Response

{
  "status": "healthy",
  "timestamp": "2026-03-03T14:32:10Z",
  "version": "1.2.0",
  "uptime": "2h15m30s",
  "services": {
    "database": "healthy",
    "redis": "healthy",
    "ccxt": "healthy",
    "telegram": "healthy"
  },
  "cache_metrics": {
    "overall": {
      "hits": 15420,
      "misses": 1230,
      "hit_rate": 0.926,
      "total_ops": 16650,
      "last_updated": "2026-03-03T14:32:10Z"
    },
    "memory_usage_bytes": 45678912,
    "connected_clients": 12,
    "key_count": 3456
  }
}

​
GET /ready

Kubernetes-style readiness check for determining if the service can accept traffic.

​
Request

curl http://localhost:3000/ready

​
Response

​
ready
boolean
required
true if all critical services are ready, false otherwise
​
services
object
required
Readiness status of each service

​
Response Codes

  • 200 OK: Service is ready to accept traffic
  • 503 Service Unavailable: Critical dependencies are not ready
The /ready endpoint is strict: it returns 503 if either the database or Redis is unavailable. Use this endpoint in Kubernetes readiness probes to prevent traffic from reaching unhealthy pods.

​
Example Response

{
  "ready": true,
  "services": {
    "database": "ready",
    "redis": "ready",
    "ccxt": "ready"
  }
}

​
GET /live

Lightweight liveness check to confirm the process is responsive.

​
Request

curl http://localhost:3000/live

​
Response

​
status
string
required
Always returns alive if the service is running
​
timestamp
string
required
ISO 8601 timestamp when the liveness check was performed

​
Response Codes

  • 200 OK: Process is alive and responsive
The /live endpoint performs minimal work and does not check dependencies. Use this in Kubernetes liveness probes to detect completely deadlocked processes that need restart.

​
Example Response

{
  "status": "alive",
  "timestamp": "2026-03-03T14:32:10Z"
}

​
HEAD /health

Identical to GET /health but returns only headers (no response body). Useful for lightweight polling. 
curl -I http://localhost:3000/health

​
Health Check Strategy

​
Kubernetes Configuration

Recommended probe configuration for NeuraTrade deployment: 
livenessProbe:
  httpGet:
    path: /live
    port: 3000
  initialDelaySeconds: 15
  periodSeconds: 20
  timeoutSeconds: 5
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 2

​
Load Balancer Configuration

For cloud load balancers (AWS ALB, GCP LB), configure health checks:
  • Path: /health
  • Interval: 30 seconds
  • Timeout: 5 seconds
  • Healthy Threshold: 2 consecutive successes
  • Unhealthy Threshold: 3 consecutive failures

​
Monitoring Integration

Health endpoints emit Sentry telemetry spans for observability:
  • health_check - Full health check with dependency status tags
  • readiness_check - Readiness probe with service availability tags
  • liveness_check - Lightweight liveness verification
Each span includes:
  • HTTP method and URL tags
  • Service status tags (database.status, redis.status, ccxt.status)
  • Overall status tags (overall.status, database.readiness)
  • Error capture for failed dependency checks

Build docs developers (and LLMs) love

Get started for freeTalk to us