Glossary · Monitoring

Liveness Probe

A liveness probe checks whether a process is still functioning, and an orchestrator restarts the instance when repeated checks fail.

Updated October 14, 2026

A liveness probe asks a narrow question: is this process alive and able to make progress, or is it deadlocked or hung? If the check fails repeatedly, the orchestrator treats the instance as broken and restarts it.

Why it matters

Some failures never crash the process. A deadlock, an exhausted thread pool, or an infinite loop leaves a program running but useless. Without a liveness check it stays that way until a person notices. With one, the platform heals itself in seconds.

Example

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3

The handler should be trivial: return 200 if the main loop can respond. It should not check the database. If the database is down and liveness fails, the orchestrator restarts every healthy instance in a loop, worsening the outage without fixing anything.

Compare with a readiness probe: liveness answers "restart me?", readiness answers "send me traffic?".

Common mistakes

  • Checking external dependencies in a liveness endpoint.
  • Setting the timeout and threshold so tight that a slow garbage collection kills a healthy pod.
  • Probing before the app has finished starting, causing restart loops. Use an initial delay or startup probe.
  • Using one endpoint for everything.

Get notified when this term updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

Keep reading

Glossary · MonitoringBlack-Box MonitoringBlack-box monitoring tests a system from the outside, the way a user would, to detect symptoms like errors and slowness without inspecting internals.Glossary · MonitoringBulkhead PatternThe bulkhead pattern isolates resources into separate pools so a failure or overload in one part of a system cannot exhaust capacity for the rest.Glossary · MonitoringFalse Negative (Monitoring)In monitoring, a false negative is a missed failure: the check reports healthy while real users are affected, so no alert is sent.Guide · MonitoringAlert Fatigue and On-Call Basics for Small TeamsSet severity levels, escalation paths, alert thresholds and runbooks so a small team gets paged for real problems only and still sleeps through the night.8 min readGuide · MonitoringCron Job Heartbeat Monitoring to Catch Silent Failures EarlyLearn how heartbeat monitoring catches silent cron failures, with copy-ready examples for crontab, systemd, GitHub Actions, Docker, WP-Cron, Laravel and more.9 min readGuide · MonitoringHow Often Should You Monitor a Website? Choosing Check IntervalsPick the right uptime check interval for each part of your site. See how interval, retries and alert delay combine into real detection time, and what to avoid.8 min read

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.