Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt

Use this file to discover all available pages before exploring further.

slipway uses three Kubernetes probe phases:
  • startup — runs first, blocks the other probes until it passes. Good for slow-booting apps.
  • readiness — gates traffic. slipway also gates cutover on readiness: a new deployment isn’t marked healthy and the Ingress isn’t switched over until every public service is Ready.
  • liveness — runs continuously after readiness passes. Failures restart the pod.
Set any subset. 
healthcheck:
  startup:   { http: { path: /startup, port: 3000 }, periodSeconds: 5,  failureThreshold: 30 }
  readiness: { http: { path: /ready,   port: 3000 }, periodSeconds: 5 }
  liveness:  { http: { path: /healthz, port: 3000 }, periodSeconds: 30 }

​
Handlers

Each probe takes exactly one handler.

​
http

readiness:
  http:
    path: /ready
    port: 3000
Considered healthy on any 2xx response.

​
tcp

readiness:
  tcp:
    port: 5432
Considered healthy if the TCP connection establishes.

​
exec

liveness:
  exec:
    command: [pg_isready]
Considered healthy on exit code 0.

​
grpc

readiness:
  grpc:
    port: 9000
Uses the standard gRPC health-checking protocol. Optional service: selects a specific service name within the gRPC server.

​
Timing fields

All four handlers accept the standard Kubernetes timing knobs:
FieldDefault behavior
initialDelaySecondsSeconds before the probe runs for the first time.
periodSecondsHow often the probe runs.
timeoutSecondsPer-probe timeout.
failureThresholdConsecutive failures before the phase fails.
successThresholdConsecutive successes required (readiness/liveness only).
If you don’t set them, slipway passes through Kubernetes’ defaults.

​
Portless services

If your service has no ports:, a readiness probe is optional. With no probe set, slipway considers the service ready as soon as the pod reaches Running. This is the right shape for workers — they don’t accept traffic, so there’s no readiness gate to wait on. For most web services, a single readiness probe is enough: 
healthcheck:
  readiness: { http: { path: /healthz, port: 3000 }, periodSeconds: 5 }
Add startup only when your app takes more than ~30 seconds to boot. Add liveness only when you’ve seen the app deadlock in a way readiness doesn’t catch.