Running your own LLM inference server with LocalAI gives you data privacy, cost control, and full ownership of your AI stack. But local model servers introduce failure modes that container health checks alone can't catch: GPU memory exhaustion, model load failures, request queue saturation, and cold-start latency spikes.
In this tutorial you'll set up comprehensive uptime and performance monitoring for your LocalAI instance using Vigilmon — free tier, no credit card required.
Why LocalAI needs external monitoring
LocalAI exposes an OpenAI-compatible REST API, which means it looks healthy to process managers even when inference is broken. Common silent failure modes include:
- Model load failure — LocalAI starts but fails to load a model (wrong path, corrupt weights, insufficient VRAM); the process is running but every inference request returns 500
- GPU memory saturation — loading a second model evicts the first; users of the first model get errors while the server process appears healthy
- Request queue overflow — under heavy load, the inference queue backs up; new requests time out or are rejected while the server itself is still "up"
- Slow first-token latency — a model swap triggered by an LRU cache eviction causes the first request after a quiet period to take 30+ seconds; no alert fires because the server is technically alive
- API regression after config change — editing
config.yamlto change model parameters silently breaks the/v1/chat/completionscontract; the process restarts successfully but returns malformed responses - Network routing failure — your LocalAI container is healthy but the reverse proxy or firewall rule in front of it is broken; clients can't connect
External monitoring from Vigilmon catches all of these because it probes the actual API endpoint from outside your infrastructure, exactly like your users and applications do.
What you'll need
- A running LocalAI instance (Docker, bare metal, or Kubernetes)
- At least one model loaded and responding to inference requests
- A free Vigilmon account (sign up takes 30 seconds)
Step 1: Confirm your LocalAI health endpoint
LocalAI ships with a built-in /health endpoint that returns HTTP 200 when the server is ready:
curl http://localhost:8080/health
# {"status":"ok"}
If you're running LocalAI in Docker:
docker run -d \
--name localai \
-p 8080:8080 \
-v /path/to/models:/models \
-e MODELS_PATH=/models \
localai/localai:latest
Wait for the model to load (watch docker logs localai), then verify:
curl http://localhost:8080/health
# {"status":"ok"}
For a more meaningful health probe, send a quick inference request using the smallest loaded model:
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "phi-2",
"messages": [{"role": "user", "content": "ping"}],
"max_tokens": 5
}'
A successful response confirms the model is loaded and inference is working, not just that the HTTP server is alive.
Step 2: Expose LocalAI behind a reverse proxy
For external monitoring to reach your LocalAI instance, it needs to be accessible via a public URL. The recommended approach is to put it behind nginx or Caddy with optional authentication.
nginx configuration:
server {
listen 80;
server_name ai.yourdomain.com;
location /health {
proxy_pass http://127.0.0.1:8080/health;
proxy_set_header Host $host;
}
location /v1/ {
# Add auth header validation here if needed
proxy_pass http://127.0.0.1:8080/v1/;
proxy_set_header Host $host;
proxy_read_timeout 120s; # LLM inference takes time
}
}
Caddy configuration:
ai.yourdomain.com {
reverse_proxy /health localhost:8080
reverse_proxy /v1/* localhost:8080 {
transport http {
read_timeout 120s
}
}
}
Verify external reachability:
curl https://ai.yourdomain.com/health
# {"status":"ok"}
Step 3: Set up HTTP monitoring in Vigilmon
With your health endpoint publicly reachable, add it to Vigilmon:
- Log in to vigilmon.online and go to Monitors → New Monitor
- Choose HTTP / HTTPS as the monitor type
- Set the URL to
https://ai.yourdomain.com/health - Set the check interval to 1 minute
- Under Expected response, configure:
- Status code:
200 - Response body contains:
"status":"ok"
- Status code:
- Save the monitor
Vigilmon probes from multiple geographic regions using multi-region consensus: your server must fail checks from several independent locations before an alert fires, eliminating false positives from transient network blips.
Step 4: Add an inference smoke-test monitor
The /health endpoint only tells you the HTTP server is alive. To confirm models are actually loading and responding, set up a second monitor on your inference endpoint.
LocalAI supports a /v1/models endpoint that lists loaded models:
curl https://ai.yourdomain.com/v1/models
# {
# "object": "list",
# "data": [
# {"id": "phi-2", "object": "model", ...},
# {"id": "llama3-8b", "object": "model", ...}
# ]
# }
In Vigilmon:
- Monitors → New Monitor → HTTP / HTTPS
- URL:
https://ai.yourdomain.com/v1/models - Check interval: 2 minutes
- Expected response:
- Status code:
200 - Response body contains:
"object":"list"(confirms the model registry responded)
- Status code:
- Save the monitor
Now if a model eviction or load failure causes /v1/models to return an empty list or an error, Vigilmon catches it within 2 minutes.
Step 5: Monitor request latency with response time thresholds
LocalAI inference latency is a key signal — a spike usually means the model was evicted from GPU memory and is reloading, or the system is under memory pressure.
In Vigilmon, set a response time alert on your /health monitor:
- Open the monitor you created in Step 3
- Go to Alerts → Response Time
- Set: Alert if response time exceeds 3000ms
- Save
A slow /health response is a leading indicator that the server is under load. You'll know about degraded performance before users start complaining about slow inference.
Step 6: Configure alert channels
Vigilmon supports email, Slack, PagerDuty, and webhook notifications. For a self-hosted AI server, the recommended setup is:
Slack alert (immediate): Get notified the moment the health check fails or response time spikes.
- Go to Settings → Notifications → Add Channel
- Choose Slack and paste your webhook URL
- In your LocalAI monitor, assign this channel under Alert Contacts
Email escalation (5-minute delay): If the issue isn't acknowledged in Slack within 5 minutes, send an email to the on-call engineer.
- Add an Email channel with your on-call address
- Set the alert delay to 5 minutes so you're not paged for transient blips
Step 7: Set up a status page
If other teams or applications depend on your LocalAI instance, expose its status via a Vigilmon public status page:
- Go to Status Pages → New Status Page
- Add both monitors (health check and model list) to the page
- Name it "AI Inference Service"
- Share the URL with dependent teams
When your GPU server needs maintenance or a model update, use Vigilmon's Maintenance Windows feature to suppress alerts and show a scheduled maintenance banner on the status page.
Common LocalAI failure scenarios and what Vigilmon catches
| Failure scenario | What Vigilmon detects |
|---|---|
| LocalAI process crashes | /health returns connection refused |
| Model fails to load | /v1/models returns empty list |
| GPU OOM during inference | Response time spike, then 500 errors |
| Reverse proxy misconfiguration | 502 or 504 on the health endpoint |
| DNS failure | Connection error from all probe regions |
| Cold-start after eviction | Response time exceeds threshold |
Conclusion
LocalAI gives you full control over your LLM inference stack, but that control comes with the responsibility of monitoring it yourself. With Vigilmon, you get:
- Multi-region health checks that confirm your API is reachable from outside your network
- Model list monitoring that catches silent inference failures
- Response time thresholds that alert you to GPU memory pressure before it becomes user-facing downtime
- Status pages to communicate service health to dependent teams
Set up your free Vigilmon account and have your LocalAI instance monitored in under 5 minutes.