Zero-Downtime Deployment for .NET

By Khimananda Oli | Last reviewed: August 2026

Achieving zero-downtime deployment for .NET requires coordinating application lifecycle events, load balancer health probes, and database schema compatibility so that users never see an error page during a release. Many teams struggle because they treat the code publish as the only variable, ignoring the fact that ASP.NET Core startup latency and connection draining are equally critical failure points. This guide covers the exact configuration patterns I use to keep production traffic flowing while swapping binaries on Linux containers or Azure App Service.

How do you configure health checks for zero-downtime deployment for .NET?

Health checks are the contract between your application and the orchestrator. Without them, Kubernetes or Azure App Service cannot distinguish between a pod that is starting up and one that has crashed, leading to premature traffic routing. For blue-green and canary deploys on Kubernetes, this distinction determines whether your rollout succeeds or triggers a cascade of 502 errors.

Distinguish readiness from liveness

Liveness probes determine if the process needs restarting; readiness probes determine if it should receive traffic. Conflating these is a common mistake. If your app takes 30 seconds to warm up caches but is otherwise alive, a liveness failure will kill it in a restart loop. Configure separate endpoints in Program.cs:

builder.Services.AddHealthChecks()
    .AddSqlServer(connectionString, name: "sql", tags: new[] { "ready" })
    .AddRedis(redisConnectionString, name: "redis", tags: new[] { "ready" });

app.MapHealthChecks("/health/live", new HealthCheckOptions
{
    Predicate = _ => false // No dependencies, just process alive
});

app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
    Predicate = check => check.Tags.Contains("ready")
});

In your Kubernetes manifest, map these explicitly. The initialDelaySeconds for readiness must exceed your observed P99 startup time. I typically set liveness to start after 10s but readiness to wait 45s for .NET APIs with EF Core context initialization.

Tune probe thresholds for .NET startup

ASP.NET Core on Linux can exhibit JIT compilation delays on first request. Set periodSeconds to 5 and failureThreshold to 3 for readiness. This gives the runtime 15 seconds of grace after the initial delay before marking the pod unready. Never set aggressive timeouts below 2 seconds; GC pauses under load can cause false negatives.

How does graceful shutdown prevent request drops in ASP.NET Core?

When a pod enters Terminating state, SIGTERM is sent. By default, Kestrel stops accepting new connections immediately but may abort in-flight requests if they don't complete within the shutdown timeout. To achieve true zero-downtime deployment for .NET, you must extend this window and signal the load balancer to stop sending traffic before the process exits.

Configure Kestrel shutdown timeout

The default HostOptions.ShutdownTimeout is 30 seconds. For APIs handling long-running transactions or file uploads, increase this in Program.cs or via environment variable DOTNET_SHUTDOWNTIMEOUTSECONDS=60. Ensure your Kubernetes terminationGracePeriodSeconds exceeds this value by at least 10 seconds to allow cleanup.

Implement custom shutdown hooks

Use IHostApplicationLifetime.ApplicationStopping to flush buffers, complete background workers, and deregister from service discovery manually if needed. This is critical when using external registries like Consul alongside Kubernetes services.

app.Lifetime.ApplicationStopping.Register(() =>
{
    logger.LogInformation("Shutdown initiated. Draining active requests...");
    // Signal background processors to stop accepting new work
    backgroundQueue.StopAccepting();
    // Wait for in-flight processing up to timeout
    backgroundQueue.WaitForCompletion(TimeSpan.FromSeconds(45));
});

This pattern ensures that even if the orchestrator considers the pod terminated, your application has already finished its work. Pair this with structured logging best practices to capture shutdown duration metrics for audit trails.

Which deployment strategy works best for .NET applications?

The right strategy depends on your tolerance for complexity versus risk. While rolling updates are the default for most Kubernetes clusters, regulated environments often require blue-green for instant rollback capability. Here is how they compare specifically for ASP.NET Core workloads in 2026.

For most Nepal-based startups and SMEs I advise, rolling updates with proper surge settings offer the best balance. Blue-green becomes necessary when you cannot guarantee backward-compatible database changes or when audit requirements demand immutable release artifacts. If you are managing sensitive data, review Kubernetes secrets management done right to ensure credentials rotate safely across both environments.

How do you handle database migrations without downtime in .NET?

Database schema changes cause more deployment failures than code bugs. In a zero-downtime deployment for .NET, old and new code versions run simultaneously. Any migration that breaks backward compatibility will crash the old pods before the new ones are ready.

Follow the expand-contract pattern

1. Expand: Add new columns or tables without removing old ones. Deploy this migration independently of code.
2. Migrate: Backfill existing rows with default values or computed data. Use a background job, not a blocking ALTER TABLE.
3. Update Code: Deploy new application code that reads/writes both old and new columns. Old code continues using old columns safely.
4. Contract: After confirming all traffic uses new code, deploy a final migration to drop deprecated columns.

Never run destructive migrations inside dotnet ef database update during container startup. Instead, use a dedicated migration job or CI pipeline step. For PostgreSQL specifically, consult PostgreSQL administration essentials for safe concurrent index creation techniques that avoid locking production tables.

Use feature flags for schema transitions

Wrap new column access in feature flags. This decouples deployment from activation. If the new schema causes performance regression, disable the flag instantly without rolling back code or reverting migrations. Tools like LaunchDarkly or simple config-driven flags in appsettings.json work effectively here.

What observability signals confirm a successful .NET deployment?

You cannot claim zero downtime without evidence. Monitoring must validate that error rates remained flat and latency percentiles did not spike during the rollout window. Relying solely on "no alerts fired" is insufficient; subtle degradations hide in averages.

Track deployment-correlated metrics

Annotate your Grafana dashboards with deployment events. Overlay HTTP 5xx rate, p95 latency, and saturation metrics against the rollout timeline. A successful zero-downtime deployment for .NET shows no correlation between the annotation and metric deviation. If you lack this visibility, implement OpenTelemetry instrumentation to capture request-level traces spanning the transition period.

Validate business transactions, not just infrastructure

Infrastructure health does not equal business health. Monitor domain-specific SLIs: orders processed per minute, authentication success rate, payment completion ratio. These catch logic errors that pass synthetic health checks. Define meaningful targets using meaningful SLIs and SLOs before attempting advanced deployment strategies.

Implementing Reliable Releases

Zero-downtime deployment for .NET is an engineering discipline, not a configuration toggle. It demands aligned health checks, respectful shutdown handling, backward-compatible data access, and verifiable observability. Start by auditing your current health endpoints and shutdown timeouts; most teams find gaps there before touching orchestration. When you are ready to harden your release pipeline or need an audit-ready compliance review for your .NET infrastructure, reach out to discuss your deployment architecture.