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.

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.

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

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement