How would you design readiness, liveness, and startup probes for an ASP.NET Core API running under an orchestrator?

Readiness, liveness, and startup probes for a .NET service

Separates traffic eligibility, process recovery, and slow startup so health checks do not amplify dependency failures or restart healthy work.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A readiness endpoint can fail while the app is starting, draining, or temporarily unable to serve its required path. Liveness should stay narrow and avoid failing merely because a shared database is briefly unavailable; restarting every replica would add load without repairing the dependency. A startup probe or sufficient startup window delays liveness enforcement until initialization has had a fair chance to finish.

Full answer below

Practice focus

Health semantics, dependency checks, startup protection, restart behavior, traffic routing, timeouts, and failure amplification.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Readiness answers whether this instance should receive traffic, liveness answers whether restarting it may recover a stuck process, and startup protects slow initialization from premature liveness failures.
A readiness endpoint can fail while the app is starting, draining, or temporarily unable to serve its required path. Liveness should stay narrow and avoid failing merely because a shared database is briefly unavailable; restarting every replica would add load without repairing the dependency. A startup probe or sufficient startup window delays liveness enforcement until initialization has had a fair chance to finish.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I give probes short timeouts and cheap checks. Readiness may include only dependencies essential to serving traffic, with bounded cached state rather than an expensive query on every probe. Liveness checks the process's own ability to make progress, such as an event loop or critical worker heartbeat, not the health of the entire world. The shutdown path flips readiness before termination so load balancers stop sending new work while in-flight requests drain.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I tune intervals and thresholds from startup and recovery measurements, including cold caches and migrations. I separate probe telemetry from user traffic so failures are visible without polluting availability metrics. A dependency outage drill verifies that replicas remain alive, readiness behavior matches the product's degraded-mode decision, and probe traffic does not create a retry storm. Probe contracts are versioned with the deployment platform because changing one endpoint can otherwise cause a fleet-wide restart loop.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using the same deep dependency check for all probes.
Restarting instances because the database is unavailable.
Running expensive queries every few seconds from every replica.
Keeping readiness true during shutdown.

Red flagsCandidateSigns the container design is fragileSignals that an interviewer may treat as risky.Open details

Details

All replicas restart together during one dependency outage.
Probe timeouts exceed their polling interval.
Startup duration regularly crosses liveness thresholds.
A health endpoint can hang indefinitely.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Should liveness check the database?
When is a startup probe useful?
How does readiness participate in graceful shutdown?

Continue the section