Operations
Health checks
What each service exposes for liveness and readiness.
Every telark service exposes a liveness and a readiness probe on the
same two paths, served on its http port:
| Probe | Path |
|---|---|
| Liveness | GET /api/v1/status/live |
| Readiness | GET /api/v1/status/ready |
Liveness answers "is this process still running"; readiness answers "can it serve traffic yet" — for the exporter that includes having the snapshot PVC mounted, for auth it includes having loaded the credential and OIDC configuration, and for discovery it includes a healthy connection to the coordination layer.
Which services have them
| Service | Probes |
|---|---|
exporter | Yes. |
discovery | Yes. |
enrichment | Yes. |
notifier | Yes. |
auth | Yes. Also the target of helm test telark -n telark. |
ui | No. The dashboard is static assets behind a web server; it serves no status route, so the chart leaves probes off (services.ui.includeHealthCheck: false). |
Probe configuration
The chart wires both probes from one shared block, identical for every service that opts in:
| Setting | Default |
|---|---|
initialDelaySeconds | 15 |
periodSeconds | 15 |
timeoutSeconds | 15 |
failureThreshold | 3 |
The defaults are conservative, tuned for cluster cold starts. Tune downward only after observing steady-state pod startup time in your own environment.