Startup checks and two health endpoints
Liveness asks only if the process is alive. Readiness reports a provider outage as degraded, not as a failure.
Deploying an LLM service means packaging it (usually in a container), giving it its settings and secrets through environment variables, exposing health checks, and respecting the time limits of the platform you run on, which matters because model calls and streams last seconds to minutes.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write readiness(config_loaded, database, provider) returning "ready", "degraded" or "not ready" following the rules of this topic, and print it for the four combinations (True, True, True), (True, True, False), (True, False, True), (False, True, True).
Write missing(env, required) returning the sorted list of required names that are absent or empty in env, and print the result for {"A": "1", "B": ""} with required ["B", "A", "C"].
Explain it without notes
What is the difference between liveness and readiness?
How should an LLM service handle settings and secrets in a container?
Why do platform time limits matter more for LLM services, and what are your options?
How do you deploy a new version without cutting active streams?
Expected output
start: ok
start: refuse to start, missing MODEL_API_KEY
liveness: 200 alive
readiness all good: 200 ready
readiness provider down: 200 ready (degraded: provider unreachable, fallback answers only)
readiness database down: 503 not ready: database unreachable
readiness booting: 503 not ready: config not loaded