Skip to content

feat(validator): add optional startupProbe - #334

Merged
devkoriel merged 1 commit into
mainfrom
feat/validator-startup-probe
Aug 25, 2026
Merged

devkoriel merged 1 commit into
mainfrom
feat/validator-startup-probe

Conversation

@devkoriel

Copy link
Copy Markdown
Contributor

What

Adds an optional startupProbe to the validator chart, for both the ghost and ghost-vao deployments. Disabled by default. Chart version 0.6.11 -> 0.7.0 (minor, new feature, no behaviour change for existing releases).

Why

The chart renders only livenessProbe and readinessProbe. That means the only way to accommodate a validator that starts slowly is to raise liveness initialDelaySeconds, which also delays steady-state failure detection: the two concerns are forced to share one number.

This bit prod. On 2026-08-18 a prod ghost pod took 182s to serve /healthz against the chart default initialDelaySeconds: 60, accumulated six Unhealthy events, and was killed 21 seconds after it finally came up (app logged normal startup, no errors; image pull took 1s). The version it replaced took exactly 60s — it had been clearing the probe with no margin at all.

A startupProbe is the mechanism designed for this: while it runs, liveness and readiness are suspended, so startup budget and failure detection are tuned independently.

Backwards compatibility

global.startup.enabled defaults to false, so existing releases render byte-identically. Verified:

helm template t charts/validator                                  -> 0 startupProbe, 2 livenessProbe
helm template t charts/validator --set global.startup.enabled=true -> 2 startupProbe, 2 livenessProbe

helm lint passes. README regenerated with helm-docs.

Usage

global:
  startup:
    enabled: true
    startupProbe:
      failureThreshold: 30   # 30 x 10s = 5 minute startup budget
      periodSeconds: 10

The template guards with and .Values.global.startup .Values.global.startup.enabled, so consumers that have not merged the new values key are safe.

Related

chronicleprotocol/app-of-apps#1922 currently works around this by raising liveness initialDelaySeconds to 300 for the prod validator. Once this chart version is adopted there, that override should be replaced with startup.enabled: true, which is the better shape.

The chart renders only livenessProbe and readinessProbe, so a slow-starting
validator can only be accommodated by raising liveness initialDelaySeconds,
which also delays steady-state failure detection. A startupProbe separates
the two: while it runs, liveness and readiness are suspended, and once it
passes they behave normally.

This is not hypothetical. On 2026-08-18 a prod ghost pod took 182s to serve
/healthz against the chart default initialDelaySeconds of 60, collected six
Unhealthy events and was killed 21s after it came up. The version it
replaced took exactly 60s, i.e. it had been clearing the probe with no
margin at all.

Disabled by default, so existing releases render unchanged (verified: helm
template with default values emits no startupProbe). Applies to both the
ghost and ghost-vao deployments. Default budget when enabled is
failureThreshold 30 x periodSeconds 10 = 5 minutes.
@devkoriel devkoriel self-assigned this Aug 19, 2026
@devkoriel devkoriel added enhancement New feature or request validator labels Aug 19, 2026
@devkoriel
devkoriel merged commit 95cd8c6 into main Aug 25, 2026
3 checks passed
@devkoriel
devkoriel deleted the feat/validator-startup-probe branch August 25, 2026 00:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request validator

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants