Msty is a privacy-first AI assistant desktop application that aggregates multiple LLM providers — including local models via Ollama, LM Studio, and Jan — alongside cloud providers like OpenAI, Anthropic, and Groq. Teams and individual developers use Msty as a unified interface for AI workflows: document analysis, code generation, and knowledge base querying. When Msty's local backend connections fail, or when the provider APIs it depends on become unreachable, the application loses functionality silently. Vigilmon gives you external visibility into Msty's infrastructure dependencies: local backend API availability, cloud provider endpoint reachability, SSL certificates on proxied deployments, and connectivity health across the provider stack your Msty instance depends on.
What You'll Build
- Monitors for the local LLM backends Msty connects to (Ollama, Jan, or LM Studio APIs)
- Cloud provider endpoint connectivity checks for APIs Msty calls on your behalf
- SSL certificate monitoring for any reverse-proxied or self-hosted components
- A composite alerting strategy that distinguishes local backend failures from cloud provider outages
Prerequisites
- Msty installed and configured with at least one provider (local or cloud)
- The local backend APIs Msty connects to (Ollama at port 11434, Jan at 1337, or LM Studio at 1234) accessible from a network-reachable URL
- A free account at vigilmon.online
Architecture note: Msty itself does not expose an HTTP server — it is a desktop client. You monitor the infrastructure Msty depends on: local model backends and cloud provider API endpoints.
Step 1: Monitor Your Local LLM Backend
Msty connects to local model servers over HTTP. The most common backend is Ollama, but Jan and LM Studio use the same OpenAI-compatible API contract. Monitor whichever backend your Msty instance is configured to use.
Ollama Backend
curl http://localhost:11434/api/tags
A healthy Ollama instance returns a models array:
{"models": [{"name": "llama3.2", "size": 2019393189}]}
Add the monitor:
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://your-ollama-proxy.example.com/api/tags. - Check interval: 60 seconds.
- Expected status:
200. - Keyword:
models. - Label:
Msty Backend - Ollama. - Click Save.
Jan or LM Studio Backend
curl http://localhost:1337/v1/models # Jan
curl http://localhost:1234/v1/models # LM Studio
Both return an OpenAI-compatible models list. Configure the monitor using the same steps above, pointing to your proxied backend URL and looking for the keyword data.
Step 2: Monitor Cloud Provider API Connectivity
Msty routes requests to cloud providers using your own API keys. While you cannot monitor Anthropic or OpenAI internals directly, you can monitor whether the provider's public API is reachable from Vigilmon's monitoring infrastructure — which is a reliable proxy for whether Msty can reach it too.
OpenAI API Availability
curl https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY"
The unauthenticated models endpoint returns 401 — which still proves the API is reachable:
- Add Monitor → HTTP.
- URL:
https://api.openai.com/v1/models. - Check interval: 5 minutes.
- Expected status:
401(unauthenticated; proves the endpoint is up). - Label:
Msty Dependency - OpenAI API. - Click Save.
Anthropic API Availability
curl https://api.anthropic.com/v1/messages \
-H "anthropic-version: 2023-06-01"
Returns 401 or 400 when reachable. Add the monitor:
- Add Monitor → HTTP.
- URL:
https://api.anthropic.com/v1/messages. - Check interval: 5 minutes.
- Expected status:
401. - Label:
Msty Dependency - Anthropic API. - Click Save.
Groq API Availability
curl https://api.groq.com/openai/v1/models
- Add Monitor → HTTP.
- URL:
https://api.groq.com/openai/v1/models. - Check interval: 5 minutes.
- Expected status:
401. - Label:
Msty Dependency - Groq API. - Click Save.
Add monitors for only the providers you have configured in Msty. Monitoring a provider you do not use adds noise without value.
Step 3: Monitor SSL Certificates
If you expose local backends via a reverse proxy with TLS, monitor those certificates. Msty connects to local backends over HTTP by default — a TLS proxy adds security but also a new failure mode:
- Add Monitor → SSL Certificate.
- Domain:
your-ollama-proxy.example.com(or Jan/LM Studio proxy domain). - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
Repeat for each proxied backend domain you use with Msty.
Step 4: Monitor Local Backend Inference
Beyond model listing, verify that your local backend can actually run inference — a model loaded in memory can still fail to complete requests if it has encountered a recoverable error state:
curl -X POST http://localhost:11434/api/generate \
-H "Content-Type: application/json" \
-d '{"model": "llama3.2", "prompt": "ping", "stream": false}'
Add a smoke-test monitor:
- Add Monitor → HTTP.
- URL:
https://your-ollama-proxy.example.com/api/generate. - Method:
POST. - Request body:
{"model": "llama3.2", "prompt": "ping", "stream": false}. - Request headers:
Content-Type: application/json. - Check interval: 10 minutes.
- Response timeout: 60 seconds.
- Expected status:
200. - Keyword:
response. - Label:
Msty Backend - Inference Smoke Test. - Click Save.
Use a longer check interval for inference tests to avoid putting constant load on local hardware.
Step 5: Configure Alerting
In Vigilmon under Settings → Notifications, configure alert channels:
| Monitor | Trigger | Action |
|---|---|---|
| Msty Backend - Ollama | Non-200 or models missing | Ollama process crashed; run ollama serve or restart the service |
| Msty Backend - Inference Smoke Test | Non-200, timeout, or response missing | Model failing to run inference; check RAM/VRAM, reload model |
| Msty Dependency - OpenAI API | Non-401 (e.g. 5xx or timeout) | OpenAI platform incident; check status.openai.com |
| Msty Dependency - Anthropic API | Non-401 (e.g. 5xx or timeout) | Anthropic platform incident; check status.anthropic.com |
| Msty Dependency - Groq API | Non-401 (e.g. 5xx or timeout) | Groq platform incident; check console.groq.com/status |
| SSL Certificate | < 30 days to expiry | Renew certificate or verify auto-renewal on your proxy |
Alert interpretation: When cloud provider monitors fire, Msty's cloud-connected models will fail but local models remain available. When local backend monitors fire, Msty's local model access fails but cloud providers continue to work. This helps you triage which providers to fall back to.
Common Msty Infrastructure Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor | |---|---| | Ollama process stops (system restart, update) | Ollama backend monitor fires | | Local model unloaded or fails to load | Inference smoke test fires; model list may stay populated | | OpenAI service disruption | OpenAI API monitor fires; use local models as fallback | | Anthropic API degradation | Anthropic API monitor fires | | Groq API outage | Groq API monitor fires | | Reverse proxy certificate expires | SSL monitor alerts at 30-day threshold | | Host machine goes to sleep | Local backend monitors all fire | | Network route to backend proxy broken | HTTP and SSL monitors fire simultaneously | | Provider API rate limit triggers 429 | Cloud provider monitors may not fire (429 means reachable); check in-app errors |
Msty's strength is its multi-provider architecture — when one LLM backend fails, others remain available. But that same architecture means multiple failure points need monitoring: local backends, cloud provider APIs, and the network paths between them. Vigilmon makes this observable: instant alerts when your Ollama or LM Studio backend goes down, when cloud provider APIs become unreachable, and when your proxy certificates approach expiry. Build the same observability around your AI assistant infrastructure that you would apply to any other critical dependency.
Start monitoring Msty's infrastructure in under 5 minutes — register free at vigilmon.online.