Comparison questionMedium~7 minResilience & Dependency Failures Essentials / 6 of 16

Interview question

What should a production API health check verify?

Design health checks for readiness, liveness, and startup

Explains health checks that prove an API can serve traffic without becoming fragile dependency probes.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would separate liveness from readiness. Liveness answers whether the process is alive and not stuck. Readiness answers whether this instance can serve traffic. Startup or warmup checks can verify configuration, routes, and required initialization before an instance receives users. Not every dependency belongs in every health check.

Full answer below

Practice focus

Readiness, liveness, startup checks, dependency checks, warmup, traffic routing, and false-positive risk.

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
Health checks decide whether traffic reaches the app. A check that is too weak hides failures; a check that is too strict causes false outages.
I would separate liveness from readiness. Liveness answers whether the process is alive and not stuck. Readiness answers whether this instance can serve traffic. Startup or warmup checks can verify configuration, routes, and required initialization before an instance receives users. Not every dependency belongs in every health check.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For readiness, I may check critical configuration, database connectivity if every request depends on it, and whether required background initialization completed. I would avoid making the health endpoint perform expensive business queries or call every optional dependency. If an optional provider is down, the app may still be ready in degraded mode. The health response should be safe and not reveal secrets.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I tune health checks with routing and restart behavior in mind. Liveness stays local to the process because tying it to a shared dependency can restart every healthy instance during one provider outage. Readiness includes only capabilities required for this instance to serve its contract, with bounded probes, failure thresholds, and carefully chosen recovery thresholds. Startup or warmup prevents traffic before initialization is complete. I track state transitions, probe duration, removed instances, and the dependency reason, then test shared outages, slow startup, rolling deployments, and recovery without creating a restart or traffic-flapping 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 one health check for every purpose.
Calling expensive or optional dependencies on every probe.
Returning sensitive configuration details.
Letting one shared dependency remove every instance from rotation unnecessarily.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain readiness versus liveness.
No timeout or threshold behavior.
No degraded-mode thinking.
Health checks fail without useful diagnostics.

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.

Which dependencies belong in readiness?
How can a health check make an outage worse?
What should warmup verify?

Continue the section

Next in Resilience & Dependency Failures Essentials: Dependencies

Step 7 of 16

Capture dependency telemetry for SQL, Redis, and HTTP calls

Opening drill

Comparison questionMedium~7 minResilience & Dependency Failures Essentials / 6 of 16

Interview question

What should a production API health check verify?

Design health checks for readiness, liveness, and startup

Explains health checks that prove an API can serve traffic without becoming fragile dependency probes.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Readiness, liveness, startup checks, dependency checks, warmup, traffic routing, and false-positive risk.

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
Health checks decide whether traffic reaches the app. A check that is too weak hides failures; a check that is too strict causes false outages.
I would separate liveness from readiness. Liveness answers whether the process is alive and not stuck. Readiness answers whether this instance can serve traffic. Startup or warmup checks can verify configuration, routes, and required initialization before an instance receives users. Not every dependency belongs in every health check.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For readiness, I may check critical configuration, database connectivity if every request depends on it, and whether required background initialization completed. I would avoid making the health endpoint perform expensive business queries or call every optional dependency. If an optional provider is down, the app may still be ready in degraded mode. The health response should be safe and not reveal secrets.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I tune health checks with routing and restart behavior in mind. Liveness stays local to the process because tying it to a shared dependency can restart every healthy instance during one provider outage. Readiness includes only capabilities required for this instance to serve its contract, with bounded probes, failure thresholds, and carefully chosen recovery thresholds. Startup or warmup prevents traffic before initialization is complete. I track state transitions, probe duration, removed instances, and the dependency reason, then test shared outages, slow startup, rolling deployments, and recovery without creating a restart or traffic-flapping 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 one health check for every purpose.
Calling expensive or optional dependencies on every probe.
Returning sensitive configuration details.
Letting one shared dependency remove every instance from rotation unnecessarily.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain readiness versus liveness.
No timeout or threshold behavior.
No degraded-mode thinking.
Health checks fail without useful diagnostics.

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.

Which dependencies belong in readiness?
How can a health check make an outage worse?
What should warmup verify?

Continue the section

Next in Resilience & Dependency Failures Essentials: Dependencies

Step 7 of 16

Capture dependency telemetry for SQL, Redis, and HTTP calls

What should a production API health check verify?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

What should a production API health check verify?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section