A practical NestJS guide to Kubernetes health checks — liveness vs readiness, Terminating pod drains, and graceful shutdown so SaaS deploys do not drop in-flight requests or queue jobs.
NestJS
Kubernetes
Health Checks
DevOps
SaaS
NestJS pods with Kubernetes liveness and readiness probes during a graceful rolling shutdown with Cyber Infoware branding
Green pods are not the same as healthy traffic. On Kubernetes, NestJS services need honest liveness and readiness probes — and a graceful shutdown that finishes in-flight HTTP requests and queue jobs before the process exits. Without that, every rolling deploy becomes a small outage your customers feel as 502s and lost webhooks.
This guide covers what each probe should mean in NestJS, how to drain a Terminating pod safely, and how Cyber Infoware kits ship Docker/Kubernetes-ready services so health and shutdown are part of the ship path — not a postmortem fix.
Why deploys drop requests without health discipline
A pod marked Ready while PostgreSQL is still connecting accepts traffic that immediately fails
SIGTERM arrives and the process exits before the load balancer stops sending new requests
Workers die mid-job with no ack — queues redeliver, but customers see duplicate side effects
Liveness that hits a slow dependency can kill healthy pods during dependency blips
Kubernetes routing NestJS traffic only to Ready pods while a Terminating pod drains gracefully
Readiness controls traffic; liveness restarts broken processes; graceful shutdown finishes work already accepted.
Liveness vs readiness vs startup — keep them distinct
Startup — give NestJS time to boot (DI, config, first connections) before other probes begin
Liveness — "should Kubernetes restart this process?" Keep it cheap: process up, event loop responsive — not a full DB query if Redis blips are common
Readiness — "should this pod receive traffic?" Check dependencies you need to serve: PostgreSQL, Redis, critical config
Never use the same expensive check for both liveness and readiness — that turns a dependency outage into a restart storm
What NestJS should expose
Separate /health/live and /health/ready (or equivalent) endpoints
Readiness fails closed when the app is shutting down — so Terminating pods leave the Service endpoints
Exclude probe paths from aggressive rate limits and auth middleware
Log probe failures with reason codes operators can act on (db_down, redis_timeout) without dumping secrets
EXPLORE PACKAGE · STARTER
Starter kit already Docker/Kubernetes shaped
NestJS Microservice Starter Kit ships an API gateway, Keycloak SSO, RabbitMQ, Redis, PostgreSQL, Docker, and Kubernetes manifests — so probes and rolling deploys attach to a stack that already runs in cluster, not a laptop-only process.
View Starter package
→
Graceful shutdown checklist for NestJS
On SIGTERM: mark not Ready first (or stop accepting new work), then wait for the Service to stop routing
Finish in-flight HTTP requests within a bounded grace period — then force close leftovers
Stop queue consumers from taking new jobs; allow active jobs to complete or nack for redelivery
Close DB and Redis pools last — after workers and the HTTP server are quiet
Set terminationGracePeriodSeconds longer than your drain budget, with margin for network lag
Verify with a deploy: zero spike in 5xx and no lost webhook/job acknowledgements
If Kubernetes can kill your NestJS pod while it is still in the load balancer pool, you do not have zero-downtime deploys — you have lucky timing.
SaaS-specific probe tips
Do not make readiness depend on every tenant database in a per-tenant DB model — check the control plane / routing DB and shared deps
Keep billing and webhook receivers Ready only when their queues and signature secrets are loaded
Alert on Ready pod count dropping during deploys, not only on CrashLoopBackOff
Pair probes with OpenTelemetry/deploy markers so "green after rollout" means traffic and health, not just Running
EXPLORE PACKAGE · ENTERPRISE
Enterprise services that deploy as a fleet
Enterprise SaaS Microservices Boilerplate ships tenant, billing, audit, and notification services with service-per-database PostgreSQL, Redis, and RabbitMQ behind a gateway — each service can carry its own live/ready contract and drain rules.
View Enterprise package
→
EXPLORE PACKAGE · PROFESSIONAL
Prefer one NestJS API with simpler ops?
Professional Multi-Tenant SaaS Boilerplate keeps a unified API with per-tenant PostgreSQL, Keycloak SSO, billing, and Admin — fewer pods to probe, still Docker/Kubernetes ready for honest readiness and clean shutdowns.
View Professional package
→
What "done" looks like
You roll a NestJS image, old pods leave the Service before they die, new pods take traffic only when Ready, and queues finish work without silent loss. That is the delivery bar modern SaaS buyers assume. Explore packages on cyberinfoware.com/products or contact us to match a kit to your Kubernetes ops goals.
Explore Cyber Infoware packages
Production NestJS SaaS foundations with commercial licensing — pick the architecture that matches your team.
NestJS Microservice Starter Kit
→
Production NestJS microservices — API gateway, Keycloak SSO, RabbitMQ, Docker, Kubernetes, and Terraform.
Enterprise SaaS Microservices Boilerplate
→
Full multi-tenant SaaS control plane as NestJS microservices — service-per-DB, billing, audit, notifications.
Multi-Tenant SaaS Boilerplate
→
Best-seller NestJS multi-tenant SaaS boilerplate — one API, per-tenant databases, billing, and Keycloak SSO.
See pricing
→
Contact us
→
Top comments (0)