Automatic retries

Set retry to restart a daemon after a failure. The default is no retries.

[daemons.api]
run = "node server.js"
ready_http = { url = "http://127.0.0.1:3000/health", timeout = "30s" }
retry = 3

This allows the initial attempt plus three retries. It applies to startup failures and errors after startup, including termination caused by health checks or resource limits.

Choose a policy

Value	Behavior
0 or false	Do not retry (default)
A positive integer	Retry up to that many times
true	Keep retrying on failure until stopped or disabled

[daemons.worker]
run = "python3 worker.py"
retry = true

Retries respond to failures. A process that completes successfully is not a crashed service; use cron to repeat a successful task.

Startup failures versus runtime failures

When it fails	Who handles the retry	Timing
Before becoming ready	The startup operation	Exponential backoff: 1s, 2s, 4s, …
After becoming ready	The supervisor in the background	Evaluated on interval ticks (general.interval, default 10s)

During startup retries, the CLI keeps waiting until readiness or failure. Runtime retries happen independently of the terminal that started the daemon. Use depends and ready checks to handle startup ordering instead of relying on failures to delay a dependent service.

One-off commands

pitchfork run accepts a retry count:

pitchfork run worker --retry 3 -- ./worker

For pitchfork start, configure retry in pitchfork.toml; it has no --retry override. You can also save a new daemon with a retry policy:

pitchfork daemons add worker --run './worker' --retry 3

Inspect or interrupt retries

pitchfork status api
pitchfork logs api --tail
pitchfork stop api

To prevent later manual or automatic starts, use pitchfork disable api. Restore it with pitchfork enable api.

Use on_retry to react to each retry and on_fail when attempts are exhausted. See lifecycle hooks.