Workloads

Health and readiness

Two probes, two different questions. Health asks "is the app still alive" and, when the answer is no often enough, does something about it. Readiness asks "is it ready for visitors" and decides only one thing: whether traffic is sent to that replica. A failed readiness never restarts anything.

The Portiger tab of a stack detail: a Health section with check type, path, port, interval, timeout, start period, retries and a When it fails select, and a Readiness section with its own check, path, port, period, timeout and failure threshold. — Both probes on a stack's Portiger tab, each with its own Test now button.

Where they are set

On a stack's Portiger tab - in the create form before it exists, and on the detail page afterwards, where each probe also has a Test now button that runs it against the real replica. In the create form the test is not offered yet; it says so: save and deploy first, then test.

Health

Check

An HTTP request, a port that answers, or a command inside the container.

Path

For an HTTP check. /health by default.

Command

For a command check, run inside the container.

Port

The port inside the container to check. Required for HTTP and port checks.

Every

How often to check. 30s by default.

Give up after

The timeout for one attempt. It has to be shorter than the interval.

Ignore failures for

A start-up grace period. Failures inside it do not count.

Tries before it counts

How many consecutive failures make it a failure. 1 to 10.

When it fails

Replace the replica, deploy the stack again, only tell me, or do nothing.

Readiness

Off means a replica is ready as soon as it runs. On means: until the probe passes, that replica is given no traffic and the stack shows Progressing rather than Healthy. Its fields are the same idea with a shorter rhythm - check, path, port, every, give up after, and how many failures make it not ready.

A published stack needs an HTTP readiness check. Only an HTTP probe can be handed to the part that publishes your domain, so a stack reached through a domain is refused a port or command readiness check, with that sentence. Health probes have no such restriction.

What is checked, and from where

Probes are run by the node the replica is on, not from the panel: a container network is not reachable from outside it. A command check is run inside the container. The stack list turns the result into the squares and the Healthy / Progressing / Unhealthy badge you see on Stacks.

Ordering start-up

When one thing has to happen before the application starts - a migration, a seed - it belongs in an init step rather than in a probe. Init steps run in order, each as a one-off container; if one exits with an error the deploy stops before the application starts, and its output is kept.