How to Monitor Tabby with Vigilmon

Tabby is an open-source, self-hosted AI coding assistant that gives your team GitHub Copilot-style code completion, chat, and documentation generation — without sending a line of code to an external service. It runs on your own GPU infrastructure, supports StarCoder, DeepSeek Coder, CodeLlama, and other backends through a unified API, and integrates with VS Code, JetBrains, and Neovim.

The catch: when your Tabby server goes down, developers don't get an error. Their IDE plugin silently falls back to no completions. They assume the AI is "being slow" and move on. Vigilmon catches Tabby outages immediately, so your team isn't coding without assistance for hours before anyone notices.

What You'll Set Up

• HTTP uptime monitor for the Tabby API health endpoint
• TCP monitor for the inference port
• Cron heartbeat to verify model inference is working end-to-end
• SSL certificate monitoring for the Tabby server

Prerequisites

• Tabby server running (Docker, bare metal, or cloud GPU)
• Tabby accessible over HTTP/HTTPS from a publicly reachable URL, or Vigilmon deployed in the same private network
• A free Vigilmon account

Why Monitor Tabby?

Tabby is developer infrastructure. When it fails, the failure is invisible to the people who rely on it most:

• IDE plugins fail silently — no error message, just no completions.
• GPU memory exhaustion causes the inference process to crash without restarting cleanly.
• Model loading failures on restart leave Tabby accepting connections but returning errors.
• Disk-full events prevent model weights from being cached, causing slow cold starts that eventually time out.

An external monitor like Vigilmon detects all of these scenarios from outside the application, independently of whether Tabby thinks it's healthy.

Key Metrics to Watch

| Signal | What It Means | |---|---| | /v1/health HTTP 200 | API server is up and accepting requests | | /v1/completions HTTP 200 | Inference pipeline is working | | Port 8080 TCP | Tabby process is running | | Inference heartbeat | Model actually completing code | | SSL certificate | TLS valid for IDE plugin connections |

Step 1: Monitor the Tabby Health Endpoint

Tabby exposes a /v1/health endpoint that returns 200 when the server is up. This is your primary uptime check:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the URL: https://tabby.yourdomain.com/v1/health
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

The health endpoint returns a JSON body including the model name and device type. Add a response content check to confirm the expected model is loaded:

• Enable Expected response body contains and enter the model name, e.g. TabbyML/DeepseekCoder-1.3B.

If Tabby restarts with a different model (or fails to load the model entirely), this check catches it.

Step 2: Verify the Completions Endpoint

The health endpoint only confirms the HTTP server is running. The completions endpoint tests the full inference path. Add a second monitor that probes it directly:

1. Add a new monitor with Type set to HTTP / HTTPS.
2. Set the URL to https://tabby.yourdomain.com/v1/completions.
3. Set Method to POST.
4. Set the request body to:

{
  "language": "python",
  "segments": {
    "prefix": "def hello():\n    "
  }
}

5. Add the header Content-Type: application/json and Authorization: Bearer YOUR_TOKEN if authentication is enabled.
6. Set Expected HTTP status to 200.

This probe sends a real completion request every minute. If the inference pipeline stalls or the GPU runs out of memory, this check will start failing before any developer notices degraded completions.

Step 3: TCP Monitor for the Tabby Port

A TCP port monitor provides a fast, low-overhead check that the Tabby process is running at all:

1. Click Add Monitor → TCP Port.
2. Enter tabby.yourdomain.com:8080 (or your configured port).
3. Set Check interval to 1 minute.
4. Click Save.

The TCP check fires faster than an HTTP check and catches cases where the HTTP server has crashed but the port is still held open by a zombie process, helping you distinguish between "process down" and "process hung."

Step 4: Cron Heartbeat for Scheduled Model Reloads

If you reload Tabby models on a schedule (nightly model updates, weekly fine-tune swaps), a heartbeat monitor confirms the reload job completed successfully:

#!/bin/bash
# reload-tabby-model.sh

# Pull updated model weights
tabby scheduler --now

# Confirm Tabby is healthy after reload
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/v1/health)

if [ "$HEALTH" = "200" ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID
fi

In Vigilmon:

1. Click Add Monitor → Cron Heartbeat.
2. Set the expected interval to match your reload schedule (e.g. 1440 minutes for daily).
3. Copy the heartbeat URL into the script above.

If the model reload fails or Tabby doesn't recover after a restart, the heartbeat goes silent and Vigilmon alerts.

Step 5: SSL Certificate Monitoring

IDE plugins connect to Tabby over HTTPS. A certificate expiry breaks every developer's connection simultaneously:

1. Open the HTTP monitor created in Step 1.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

If you use a wildcard cert or a certificate managed by a reverse proxy (nginx, Caddy, Traefik), add a dedicated monitor for the Tabby subdomain in addition to any existing domain-level SSL checks.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add your team's Slack channel or email.
2. For all Tabby monitors, set Consecutive failures before alert to 2 — GPU inference can occasionally spike in latency without being truly down.
3. Route alerts to an engineering Slack channel rather than individual email — Tabby outages affect the whole team simultaneously.

Consider adding a public status page in Vigilmon. When Tabby goes down, developers will ask "is Tabby down?" in Slack. A status page URL in the Slack channel topic lets them self-serve the answer.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP health | /v1/health | Server process down | | HTTP completions | /v1/completions (POST) | Inference pipeline broken | | TCP port | :8080 | Process crash | | Cron heartbeat | Model reload script | Failed model update | | SSL certificate | Tabby domain | TLS expiry breaking IDE plugins |

Self-hosting Tabby means owning its uptime. With Vigilmon watching the health endpoint, inference pipeline, and certificate, you get immediate alerts when your team's AI assistant goes dark — instead of finding out hours later when a developer mentions the completions "seem off."