Readiness probe for load balancer routing
GET /api/system/status/ready
Readiness probe endpoint for load balancer routing decisions.
Checks if the service is ready to handle requests. Unlike liveness probe, readiness can fluctuate based on system state (e.g., during startup, maintenance, or high load). Returns detailed check results including startup completion and failure status. Load balancers use this to route traffic only to ready instances.
Returns:
- ReadinessResponse: Readiness status with the following fields:
- status: Readiness status string (‘ready’ or ‘not_ready’)
- ready: Boolean readiness flag for quick checking
- checks: Dictionary of individual readiness check results
- timestamp: Current server timestamp when probe executed
Raises:
- HTTPException(500): If readiness check fails
Readiness Checks:
- startup_complete: True if backend initialization finished successfully
- no_startup_failure: True if no startup errors occurred
Cloud-Native Usage:
- Kubernetes: Configure as readinessProbe for traffic routing
- Load Balancers: Health check for instance pool management
- Auto-scaling: Determine if instance can handle new requests
- Rolling Updates: Verify new instances ready before routing traffic
Probe Configuration:
readinessProbe:
httpGet:
path: /status/ready
port: 37737
initialDelaySeconds: 5
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 2Difference from Liveness:
- Liveness: Is process alive? (restart if fails)
- Readiness: Can handle traffic? (remove from load balancer if fails)
Responses
Section titled “ Responses ”Successful Response
Readiness probe response for load balancer routing decisions.
Used by load balancers to determine if traffic should be routed to this instance. Includes detailed check results and overall readiness flag.
Fields: status: Readiness status (‘ready’ or ‘not_ready’) ready: Boolean readiness flag for quick checking checks: Dictionary of individual readiness check results timestamp: Current server timestamp when probe was executed