Vercel adds HTTP liveness probes to Daemons with automatic container restarts

Vercel has added HTTP liveness checks to Daemons, giving the platform a way to detect long-running processes that have degraded without crashing. According to the Vercel changelog, you configure a health endpoint inside your daemon and Vercel requests it periodically; once the endpoint starts failing, Vercel restarts the daemon's container.

How the configuration works

The daemon configuration now accepts a livenessProbe field. In the example Vercel published, the probe takes the form of an HTTP GET against a port and path served by the daemon itself — port 1234 and /health in the sample config. Vercel says the Daemon documentation lists the default values and optional tuning fields for the probe, though the changelog entry itself does not spell out what those defaults are.

The surrounding config confirms that Daemons are container-based workloads: the same example pairs the probe with a root directory and a Dockerfile entrypoint.

Writing a good health endpoint

Vercel's guidance is to keep the endpoint minimal so it replies quickly, and to have it respond with an error status once the daemon can no longer do its job. The changelog walks through a minimal implementation: a worker tracks an internal alive flag, flips it to false when its connection errors out, and serves a tiny HTTP response — 200 while the flag is set, 500 after it clears.

The real design question is what "healthy" means for a particular daemon. An endpoint that merely proves the HTTP server is listening establishes very little; one that reflects the daemon's actual dependencies — its queue, database connection or upstream services — is what turns the probe into a genuine safety net.

Running is not the same as healthy

The problem being addressed here is familiar to anyone who operates long-running processes. A worker can deadlock, exhaust its connection pool, or wedge permanently after an upstream failure, all while its container keeps running and consuming resources. Restart-on-exit supervision only notices a process that has actually terminated; it has nothing to say about a process that is stuck.

An application-level health endpoint addresses this by letting the process report for itself when it has stopped making progress. It is the same idea Kubernetes popularized with its liveness probes, so teams bringing long-running workloads to Vercel will find the mental model immediately familiar.

Why it matters

Daemons sit outside the request/response cycle, which means no incoming traffic naturally surfaces a wedged worker. Liveness checks close the gap between "the container exists" and "the daemon is doing useful work" — a baseline requirement for running background or stateful workloads in production.

Two operational consequences follow from the restart behaviour. First, a restart discards in-flight work, so daemons need to tolerate being interrupted mid-task; idempotent, resumable work patterns become more important once the platform can replace a container on its own judgement. Second, the health endpoint itself becomes critical in both directions: a check that is too strict can trigger restart loops under transient pressure, while one that is too loose simply recreates the blind spot the feature is meant to remove.

For Vercel, the addition is a further signal that the platform is courting workloads that do not fit the serverless model, borrowing reliability primitives that infrastructure teams already know how to reason about.