Kubernetes Liveness vs Readiness Probes

Introduction

Deploying applications to Kubernetes is only the first step toward building reliable cloud-native systems. Kubernetes must also know whether your application is running correctly, ready to receive traffic, or needs to be restarted after a failure.

This is where Liveness and Readiness Probes play a crucial role. These health checks enable Kubernetes to monitor application health, restart unhealthy containers automatically, and ensure that only healthy instances receive incoming requests.

In this article, you'll learn the differences between Liveness and Readiness Probes, how to configure them in Kubernetes, and best practices for ASP.NET Core applications.

What Are Kubernetes Probes?

Kubernetes probes are automated health checks performed by the kubelet to determine the state of a container.

There are three types of probes:

Liveness Probe
Readiness Probe
Startup Probe

Each serves a different purpose in managing application lifecycle and availability.

Why Are Probes Important?

Without health checks, Kubernetes cannot accurately determine whether an application is functioning correctly.

Probes help:

Automatically restart failed containers
Prevent unhealthy pods from receiving traffic
Improve application availability
Support zero-downtime deployments
Detect application hangs
Improve cluster reliability

Properly configured probes contribute to a more resilient application.

Liveness Probe Explained

A Liveness Probe determines whether an application is still running correctly.

If the liveness probe fails repeatedly, Kubernetes restarts the container.

Typical scenarios include:

Deadlocks
Infinite loops
Hung processes
Applications that stop responding

The goal is to recover automatically from failures without manual intervention.

Readiness Probe Explained

A Readiness Probe determines whether an application is ready to accept requests.

If the readiness probe fails:

The container continues running.
Kubernetes removes the pod from the Service endpoints.
Traffic is no longer routed to that pod.

Once the application becomes ready again, Kubernetes automatically resumes sending traffic.

Liveness vs Readiness

The following table highlights the differences.

Feature	Liveness Probe	Readiness Probe
Detects Application Failure	Yes	No
Controls Traffic Routing	No	Yes
Restarts Container	Yes	No
Removes Pod from Service	No	Yes
Purpose	Recover from failures	Accept traffic safely

In many production deployments, both probes are configured together.

Expose a Health Endpoint

ASP.NET Core provides built-in health checks that integrate well with Kubernetes.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks();

var app = builder.Build();

app.MapHealthChecks("/health");

app.Run();

The /health endpoint can now be used by Kubernetes probes.

Configure a Liveness Probe

The following example configures an HTTP-based liveness probe.

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

This configuration instructs Kubernetes to check the /health endpoint every 10 seconds after an initial delay.

If the probe fails three consecutive times, Kubernetes restarts the container.

Configure a Readiness Probe

A readiness probe can use the same or a dedicated endpoint.

readinessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 3
  failureThreshold: 3

If the endpoint becomes unavailable, Kubernetes temporarily removes the pod from load balancing until it recovers.

Configure a Startup Probe

Applications with long startup times can benefit from a Startup Probe.

startupProbe:
  httpGet:
    path: /health
    port: 80
  failureThreshold: 30
  periodSeconds: 5

The startup probe prevents Kubernetes from restarting a container before it has finished initializing.

Once the startup probe succeeds, the liveness and readiness probes take over.

Create Separate Health Checks

In production environments, it's often useful to expose separate endpoints.

Example:

/health/live
/health/ready

This allows each endpoint to represent a different aspect of application health.

For example:

/health/live verifies that the application process is running.
/health/ready verifies that required dependencies, such as databases or message queues, are available.

Configure Tagged Health Checks

ASP.NET Core supports tagged health checks to expose different endpoints.

builder.Services.AddHealthChecks()
    .AddCheck<DatabaseHealthCheck>(
        "Database",
        tags: new[] { "ready" });

Then map separate endpoints.

app.MapHealthChecks("/health/live");

app.MapHealthChecks("/health/ready");

This approach provides greater flexibility for Kubernetes deployments.

Choose Appropriate Probe Settings

Probe configuration should reflect your application's behavior.

Consider tuning:

initialDelaySeconds
periodSeconds
timeoutSeconds
failureThreshold
successThreshold

Avoid overly aggressive values that may cause unnecessary restarts during temporary slowdowns.

Best Practices

Follow these recommendations when configuring Kubernetes probes:

Implement both liveness and readiness probes.
Use dedicated health endpoints when appropriate.
Configure startup probes for applications with long initialization times.
Keep health check endpoints lightweight and fast.
Validate critical dependencies in readiness checks.
Avoid performing expensive operations inside health endpoints.
Test probe behavior before deploying to production.
Monitor probe failures using your observability platform.

These practices improve reliability and reduce unnecessary disruptions.

Common Mistakes to Avoid

Incorrect probe configuration can negatively affect application stability.

Avoid these common mistakes:

Using the same health logic for every probe.
Restarting applications because of temporary dependency failures.
Configuring timeouts that are too short.
Ignoring startup time for large applications.
Performing database-intensive operations in liveness checks.
Failing to monitor repeated probe failures.

Proper configuration ensures Kubernetes makes informed decisions about application health.

Conclusion

Kubernetes Liveness and Readiness Probes are essential for running reliable, self-healing applications in production. While liveness probes detect and recover from application failures by restarting unhealthy containers, readiness probes ensure that only healthy instances receive traffic.

For ASP.NET Core applications, combining built-in health checks with well-configured Kubernetes probes provides a robust monitoring strategy that improves availability, supports zero-downtime deployments, and enhances the overall resilience of your cloud-native applications.