# vLLM is running but not ready: health checks and the first request

Check vLLM readiness in stages: process status, HTTP health, advertised model names and a small generation request after a clean restart.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/vllm-health-ready/
Language: en

A running vLLM process does not prove that the model can serve requests. It may still be downloading weights, loading them onto the GPU, compiling components or warming up. Check three separate conditions: the process is alive, the HTTP interface responds, and a small generation request succeeds.

## Record the startup stages

Write down when the container starts, when checkpoint files become available, when weight loading finishes, when the API responds and when the first valid answer arrives. A repeated launch with files already cached can behave differently from a cold start.

Do not use an excessively short restart interval. An automated supervisor can repeatedly interrupt normal preparation and make a healthy installation appear permanently broken. Use the log to distinguish ongoing preparation from a failure after GPU initialization. Keep the original error before restarting anything.

## Test HTTP availability separately

Check the health route supported by your installed version, such as `/health`, and record the expected status. A successful response confirms that particular health check; it does not replace a request that exercises tokenization and generation.

Specify a bounded waiting period in the operating procedure. The person running the test should know when to continue waiting and when to inspect the log. A client should also preserve a useful error when the server is temporarily unavailable, rather than waiting indefinitely or hiding the first failure.

## Match the requested model to the server

Once HTTP is available, request `/v1/models` and use the advertised identifier. This matters when the server uses an alias. Send a short, non-sensitive message with a small output limit and save the status, elapsed time and response structure.

A model-name error, a chat-template error and an out-of-memory error belong to different diagnostic branches. Do not combine them into a single conclusion that the server is not working. A readiness probe should stay small enough to identify a broken path without becoming a load benchmark.

## Repeat after a clean restart

Stop the process normally, start it with the same recorded settings and repeat the control request. Confirm GPU access, model paths, directory permissions and environment variables. A command that works in an interactive shell may depend on variables missing from a service.

If weights download again, investigate persistent storage. If the address changes, investigate binding and port publication. Your report should distinguish a loaded model, a successful short answer and a tested production-like workload. Those are different levels of evidence about the machine and its recovery procedure.

## Turn the check into a practical next step

Treat process liveness, HTTP availability and successful generation as separate acceptance checks; record which one your test actually confirms.

For the documented details, consult the [primary documentation](https://docs.vllm.ai/en/stable/serving/online_serving/); [configuration reference](https://docs.vllm.ai/en/stable/cli/serve/). Continue with [vllm served model name](/journal/vllm-served-model-name/) and [vllm localhost container port](/journal/vllm-localhost-container-port/).