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:
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.
Register health checks in Program.cs.
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.