Monitoring TabbyML (Tabby) with Vigilmon

TabbyML (Tabby) is the leading open-source, self-hosted AI code completion server — a drop-in alternative to GitHub Copilot that runs entirely on your own infrastructure. Written in Rust and exposing an OpenAI-compatible API, it supports CodeLlama, StarCoder, DeepSeek-Coder, and other code models, and integrates with VS Code, JetBrains, Vim, and Neovim via the Tabby language server. But a self-hosted Copilot replacement is only valuable when it's running: if the Rust server process crashes, the model fails to load after a restart, or the inference backend becomes unresponsive, every developer in your organization loses code completions — typically with no error message beyond a timeout in their editor. Vigilmon gives you HTTP uptime monitors for Tabby's web UI and API endpoints, SSL certificate alerts for proxied deployments, and a heartbeat probe on the /v1/health endpoint that confirms the model is loaded and serving completions.

What You'll Set Up

HTTP uptime monitor for the Tabby web UI (port 8080)
/v1/health REST API health endpoint monitor
/v1beta/completions authenticated endpoint availability check
SSL certificate expiry alerts for HTTPS-proxied deployments
Cron heartbeat that probes /v1/health to confirm model loading and inference readiness

Prerequisites

Tabby server running on a server or workstation (port 8080 by default)
A Tabby API token for authenticated endpoint checks (generated via the Tabby web UI under Settings → Team)
A free Vigilmon account

Step 1: Monitor the Tabby Web UI

Tabby serves a web dashboard on port 8080. Add a Vigilmon HTTP monitor to confirm it is reachable:

Log in to vigilmon.online and click Add Monitor.
Set Type to HTTP / HTTPS.
Enter the URL: http://your-server-ip:8080 (or https://tabby.yourdomain.com if reverse-proxied).
Set Check interval to 1 minute.
Set Expected HTTP status to 200.
Click Save.

A 200 on the root path confirms the Rust HTTP server is alive. If you proxy Tabby through nginx or Caddy, use the proxied domain URL so SSL can also be monitored in a later step.

Step 2: Monitor the `/v1/health` REST API Endpoint

Tabby exposes a /v1/health endpoint that returns the server's health status including the currently loaded model and device information. This is the primary health signal for the Tabby service:

Click Add Monitor → HTTP / HTTPS.
Enter the URL: http://your-server-ip:8080/v1/health
Set Method to GET.
Set Expected HTTP status to 200.
Under Response body check, enter "model" to confirm the loaded model name is present in the response.
Set Check interval to 1 minute.
Click Save.

The /v1/health response looks like:

{
  "device": "cuda",
  "model": "TabbyML/DeepSeek-Coder-6.7B",
  "chat_model": null,
  "version": { "build_date": "...", "git_describe": "..." }
}

A missing model field or a non-200 response means the model failed to load or the inference backend is unhealthy.

Step 3: Monitor the `/v1beta/completions` Endpoint

The /v1beta/completions endpoint is the core API that all editor plugins use to request code completions. Monitoring it confirms that authenticated requests reach the inference layer:

Click Add Monitor → HTTP / HTTPS.
Enter the URL: http://your-server-ip:8080/v1beta/completions
Set Method to POST.

Under Request headers, add:

Authorization: Bearer YOUR_TABBY_API_TOKEN
Content-Type: application/json

Under Request body, enter a minimal completion request:

{"language": "python", "segments": {"prefix": "def hello"}}

Set Expected HTTP status to 200.
Set Check interval to 5 minutes.
Click Save.

Replace YOUR_TABBY_API_TOKEN with a token from the Tabby dashboard (Settings → Team → Generate Token). A 401 response means the token has been rotated or revoked; a 500 means the inference backend failed.

Step 4: SSL Certificate Alerts for HTTPS Deployments

Tabby does not handle TLS natively. In production, it is typically reverse-proxied with nginx or Caddy. An expired certificate silently breaks all editor plugin connections — developers see timeout errors rather than a clear connection failure, making the root cause hard to diagnose without explicit certificate monitoring.

Open the HTTP monitor for your proxied Tabby domain (e.g. https://tabby.yourdomain.com) created in Step 1.
Enable Monitor SSL certificate under the SSL section.
Set Alert when certificate expires in less than 21 days.
Click Save.

For nginx with certbot, verify auto-renewal:

certbot renew --dry-run
systemctl status certbot.timer

A 21-day alert window gives you three weekly renewal attempts before the certificate expires.

Step 5: Heartbeat Monitoring for Model Loading and Inference Readiness

Tabby starts quickly, but loading a large code model (DeepSeek-Coder 6.7B, StarCoder2 15B) takes 30–120 seconds. If the model loading process crashes or the GPU runs out of memory mid-load, the server may start accepting HTTP requests while returning empty or error completions — the /v1/health endpoint returns 200 but model inference is broken.

Use a periodic heartbeat probe that checks /v1/health for a valid model field:

In Vigilmon, click Add Monitor → Cron Heartbeat.
Name it Tabby model readiness probe.
Set the expected ping interval to 5 minutes.
Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Create a probe script:

#!/bin/bash
HEALTH=$(curl -s http://localhost:8080/v1/health)

# Check that a model is loaded (model field is not null)
MODEL=$(echo "$HEALTH" | python3 -c \
  "import sys,json; h=json.load(sys.stdin); print(h.get('model') or '')" 2>/dev/null)

if [ -n "$MODEL" ]; then
  # Model is loaded and server is healthy
  curl -s https://vigilmon.online/heartbeat/abc123
else
  echo "Tabby model not loaded. Health response: $HEALTH" >&2
fi

Schedule it:

# /etc/cron.d/tabby-heartbeat
*/5 * * * * root /usr/local/bin/tabby-probe.sh >> /var/log/tabby-hb.log 2>&1

If the Tabby server crashes and restarts, it will return a null model for the duration of model loading — the heartbeat stops pinging and Vigilmon alerts your team before any developer notices their completions are missing.

Step 6: Configure Alert Channels

Go to Alert Channels in Vigilmon and add Slack, email, or a webhook targeting your engineering team.
Set Consecutive failures before alert to 2 on the web UI monitor — Tabby can take 1–2 minutes to restart and load a large model.
Set the /v1/health and heartbeat monitors to alert on first failure — inference failures are not transient.
Consider a dedicated alert channel for Tabby, since all developers are affected simultaneously when it goes down.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web UI | http://your-server:8080 | Rust server crash, server down | | Health API | /v1/health | Model not loaded, backend failure | | Completions API | /v1beta/completions | Auth failure, inference layer failure | | SSL certificate | HTTPS reverse proxy domain | Let's Encrypt / Caddy renewal failure | | Cron heartbeat | /v1/health model probe | Model crash, failed load, GPU OOM |

TabbyML gives your engineering team a private, on-premise AI code completion service with zero data leaving your infrastructure — but that privacy requires you to own every availability concern that GitHub Copilot manages for you. With Vigilmon watching Tabby's web UI, health API, completions endpoint, SSL certificate, and model loading state via periodic heartbeat, every developer on your team can rely on their AI assistant being available when they need it.