Confirmed behaviorA liveness probe catches a process that has not exited but is stuck. It is not a dependency monitor, a readiness gate or proof that the last job completed correctly.
Vercel Daemons liveness checks use an internal HTTP endpoint
Vercel's October 30 changelog adds an optional livenessProbe to each Daemon configuration. Vercel sends HTTP GET requests from inside the instance and restarts the container after enough consecutive failures.
The feature catches a process that is still present while its work loop is deadlocked, disconnected or unable to progress. A queue worker can look alive while it has stopped taking messages.
A response from 200 through 399 succeeds. Vercel does not follow redirects, but a 3xx still counts as success. Connection errors, timeouts and other status codes fail the check.
| Field | Default | Operational meaning |
|---|---|---|
| initialDelaySeconds | 0 seconds | The first check can run as soon as the container starts |
| periodSeconds | 10 seconds | Each instance is checked on its own schedule |
| timeoutSeconds | 1 second | A slower response counts as a failure |
| failureThreshold | 3 | Three consecutive failures trigger a restart |
| successThreshold | 1 in the current controller | One success resets the failure count |
Check the worker's ability to progress, not every dependency
A useful liveness endpoint answers a narrow question: can this process still run its work loop? Vercel explicitly recommends keeping the endpoint cheap and basing it on progress rather than downstream dependencies.
Consider a worker that consumes invoice jobs. It can update an internal heartbeat after each queue poll and mark itself unhealthy when its queue connection enters an unrecoverable state. A temporary billing API outage should stay visible in job retries and monitoring, not necessarily kill every worker.
If /health queries the database, queue, billing provider and model API, one incident can restart all instances at once. Keep dependency health in separate signals unless the process cannot recover without a restart.
A liveness restart skips graceful shutdown
Vercel's Daemon documentation says liveness-triggered restarts use immediate SIGKILL. They do not honor terminationGracePeriodSeconds, unlike a normal rollout or scaling change that sends SIGTERM first.
That means the worker may stop in the middle of a job. An image processor could upload the new file and die before acknowledging the queue message. The retry then sees the same message and may upload a duplicate unless the job uses a stable idempotency key or checks the existing result.
Design the recovery path before the endpoint. Acknowledge work only after durable completion, make writes safe to repeat and record enough state to distinguish “not started,” “in progress” and “finished.” The probe can restart compute. It cannot repair ambiguous business state.
Probe timing must match startup and recovery behavior
The defaults are a starting point, not a universal service level. A worker that loads a large model or warms a local index may need an initial delay. A worker whose loop should respond in milliseconds may justify the one-second timeout.
Set initialDelaySeconds long enough for a normal start, then inject the real stuck condition. Confirm that the endpoint fails, three checks accumulate, the container restarts and the interrupted job completes exactly once.
The configuration reference says a changed probe applies only to instances started after deployment. Verify the running instance generation instead of assuming an edited file changed every existing worker immediately.
Public Beta limits still shape the rollout
Daemons remain in Public Beta on all plans. They run only in production deployments, while preview deployments, autoscaling and persistent storage are not supported. vercel dev does not run them.
A team cannot prove the complete behavior by opening a preview URL. Run the worker locally in its container, simulate a stalled loop and test queue redelivery. Then deploy a low-risk production consumer with a narrow queue or test job type before attaching the probe to a critical workload.
The existing Vercel Daemons Public Beta analysis covers workload fit and platform boundaries. The new question is narrower: whether the worker exposes a trustworthy signal and can survive the restart that signal requests.
Use this checklist before enabling the probe
Treat the health endpoint and the retry design as one change. The following checks should pass before the probe controls a production worker.
- The endpoint is served by the same process as the work loop.
- Its result reflects local progress rather than the health of every dependency.
- Normal startup completes before the first configured probe.
- A forced stall fails the endpoint and triggers the expected restart.
- Interrupted jobs are safe to retry and do not create duplicate effects.
- Logs and alerts preserve the cause that existed before the restart.
- The team can disable the probe or scale the Daemon down if restarts loop.
Watch restart causes, job age and duplicate effects next
A healthy process can still produce wrong work, and a frequently restarted process can still look busy. Monitor liveness failures beside queue age, retries, dead-letter volume, job duration and duplicate side effects.
For an AI document worker, track repeated uploads or charges for the same document ID. If those controls do not exist, add them before the probe. A maintenance operating plan should name who investigates restarts and can pause the consumer.