Monitoring Jan with Vigilmon: Local LLM API Uptime, Model Availability, SSL & Endpoint Health Checks

Jan is an open-source desktop application for running large language models entirely on your own hardware. Its built-in API server exposes an OpenAI-compatible REST interface on port 1337, letting you swap Jan in as a local inference backend for any application that talks to OpenAI. When that local API server is down — whether from a crash, a failed model load, or a resource exhaustion event — your dependent applications fall back to errors rather than graceful degradation. Vigilmon gives you external visibility into Jan's API health so you know about failures the moment they happen: API server availability, model endpoint responsiveness, SSL certificate status on proxied deployments, and inference endpoint uptime.

What You'll Build

• A health check on Jan's local API server
• A monitor on the models listing endpoint to confirm at least one model is loaded
• An inference endpoint smoke-test to verify Jan can actually serve requests
• SSL certificate monitoring for reverse-proxied Jan deployments
• Alerting calibrated to local inference workloads

Prerequisites

• Jan installed and running with the API server enabled (Settings → Advanced → API Server on port 1337)
• Jan accessible from a network location Vigilmon can reach — either via a reverse proxy (recommended), a VPN endpoint, or a publicly accessible server running Jan
• A free account at vigilmon.online

Local vs. remote monitoring: Vigilmon checks your endpoints from external monitoring infrastructure. For a Jan instance running only on localhost, expose it via a reverse proxy (Nginx, Caddy, Traefik) before adding it to Vigilmon. For internal-only deployments, consider Vigilmon's agent-based monitoring if available, or expose a health endpoint via your reverse proxy.

Step 1: Verify Jan's API Server Is Running

Jan's API server exposes its health and version info at the root endpoint. Confirm it responds:

curl http://localhost:1337/v1/models

A healthy response returns a JSON object with a data array listing available models:

{
  "object": "list",
  "data": [
    {
      "id": "mistral-7b-instruct",
      "object": "model"
    }
  ]
}

If you receive a Connection refused error, open Jan and navigate to Settings → Advanced → API Server and ensure the server is enabled and listening on port 1337.

Once accessible via your reverse proxy at a public URL, add the monitor:

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://your-jan-proxy.example.com/v1/models.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Keyword: data (always present when at least one model is loaded).
6. Label: Jan API - Models Endpoint.
7. Click Save.

Model availability signal: If the data array is empty, Jan is running but no model is loaded. The keyword data confirms the key exists — if you need to verify a model is loaded, use a more specific keyword like the model ID you always expect to be available.

Step 2: Monitor the OpenAI-Compatible Chat Endpoint

Jan exposes a /v1/chat/completions endpoint that follows the OpenAI API contract. This is the endpoint your applications actually call for inference. A running server that fails to handle completions — due to a crashed model process, VRAM exhaustion, or a corrupted model file — will return errors on this route even if the models list endpoint responds fine.

Add a lightweight probe using a minimal completion request:

curl -X POST http://localhost:1337/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-7b-instruct",
    "messages": [{"role": "user", "content": "ping"}],
    "max_tokens": 1
  }'

A healthy Jan instance returns 200 with a completion object. Add a monitor:

1. Add Monitor → HTTP.
2. URL: https://your-jan-proxy.example.com/v1/chat/completions.
3. Method: POST.
4. Request body:

   {"model": "mistral-7b-instruct", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 1}
   

5. Request headers: Content-Type: application/json.
6. Check interval: 5 minutes (inference is computationally expensive; avoid hammering the endpoint).
7. Response timeout: 30 seconds (first-token latency on local hardware can be high).
8. Expected status: 200.
9. Keyword: choices.
10. Label: Jan API - Inference Endpoint.
11. Click Save.

Why a longer timeout: Local LLM inference on CPU or consumer GPUs can take 5–20 seconds for a first token. A 10-second timeout that works for API services will generate false alerts on every check. Set the response timeout to at least 30 seconds, or longer if your hardware is slower.

Step 3: Monitor SSL Certificates on Your Reverse Proxy

If you expose Jan behind a reverse proxy with TLS (strongly recommended for any non-localhost access), monitor the SSL certificate on that domain. Jan itself does not manage TLS — your proxy does — and a lapsed certificate will cause all dependent applications to fail with certificate errors before Jan itself has any problem:

curl -v https://your-jan-proxy.example.com 2>&1 | grep -i "expire"

Add SSL monitoring:

1. Add Monitor → SSL Certificate.
2. Domain: your-jan-proxy.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

If you use Let's Encrypt with Caddy or Certbot, certificates renew automatically — but automation can fail. An early warning at 30 days gives you time to diagnose a failed renewal before your certificate actually expires.

Step 4: Monitor the Jan Server Info Endpoint

Jan exposes a server info endpoint that returns the version and configuration of the running instance:

curl http://localhost:1337/

This is a lightweight probe that confirms the Jan HTTP server process is alive without triggering any model loading or inference:

1. Add Monitor → HTTP.
2. URL: https://your-jan-proxy.example.com/.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Label: Jan API - Server Process.
6. Click Save.

Run this alongside the models endpoint monitor. If this fires but the models endpoint does not, the API server process is running but model loading has failed.

Step 5: Configure Alerting

In Vigilmon under Settings → Notifications, configure alert channels for your team:

| Monitor | Trigger | Action | |---|---|---| | Jan API - Server Process | Non-200 or timeout | Jan process crashed; restart Jan desktop app or the server process | | Jan API - Models Endpoint | Non-200 or data keyword missing | No models loaded; open Jan and load a model manually | | Jan API - Inference Endpoint | Non-200, timeout, or choices missing | Model loaded but inference failing; check VRAM/RAM usage, restart model | | SSL Certificate | < 30 days to expiry | Renew certificate or verify auto-renewal is working on your proxy |

Alert sensitivity for local inference: Local hardware can be resource-constrained. Set the inference endpoint monitor to alert after 2 consecutive failures to avoid noise from occasional slow cold-starts. Set process and models endpoint monitors to alert after 1 failure since those are fast checks with no hardware variability.

Common Jan Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Jan application crashes or is closed | Server Process monitor fires immediately | | Model fails to load (corrupt file, OOM) | Models Endpoint returns empty data; keyword alert fires | | VRAM exhausted mid-inference | Inference Endpoint returns error or times out | | Reverse proxy configuration broken after update | Server Process monitor fires; SSL monitor stays green | | SSL certificate expires on proxy domain | SSL monitor alerts at 30-day threshold | | Jan API server port conflicts with another process | Server Process and Models Endpoint monitors both fire | | Network route to Jan proxy goes down | All HTTP monitors fire simultaneously |

Jan gives developers a fully local, privacy-preserving inference backend that works offline and requires no API keys. But local infrastructure does not have the same resilience as cloud services — crashes, resource exhaustion, and manual interventions are more common. Vigilmon adds the external uptime visibility that local deployments lack: know instantly when Jan's API server stops responding, when no model is loaded for inference, or when your reverse proxy certificate is about to expire.

Start monitoring Jan in under 5 minutes — register free at vigilmon.online.