tutorial

Monitoring Plandex with Vigilmon: AI Coding Server, LLM Backend & Plan Execution Health

How to monitor Plandex with Vigilmon — Plandex server availability, LLM API health, plan execution reliability, and alerting for AI coding planning and execution outages.

Plandex is an open-source AI coding planning and execution tool that breaks complex software engineering tasks into plans — sequences of file changes, command runs, and explanations — and applies them step-by-step with LLM assistance. Unlike single-shot code generation tools, Plandex builds and refines a persistent plan that developers can review, approve, and iterate on before changes land in the codebase. It runs a local or self-hosted server that manages plan state, coordinates LLM calls, and applies changes through a version-controlled context mechanism. When the Plandex server or its LLM backends become unavailable, in-progress plans are interrupted and developer workflows are stalled. Vigilmon gives you external visibility into the Plandex server, the LLM APIs it calls, and any model gateways in the request path, so outages surface before developers lose plan context or apply incomplete changes.

What You'll Build

  • An HTTP monitor for the Plandex server health endpoint
  • Monitors for the LLM API backends Plandex routes requests to
  • SSL certificate monitoring for the Plandex server and LLM API domains
  • An alerting setup that separates Plandex server failures from LLM backend failures

Prerequisites

  • Plandex server running (self-hosted via plandex-server binary or the official Docker image)
  • plandex CLI installed and authenticated against your server
  • Knowledge of which LLM provider Plandex is configured to use
  • A free account at vigilmon.online

Step 1: Identify Your Plandex Deployment

Plandex operates with a client (plandex CLI) and a server (plandex-server) that stores plan state and orchestrates LLM calls. The server is the component to monitor externally. Common deployment patterns:

  1. Local development server — plandex-server running on localhost, accessed only by the local plandex CLI
  2. Shared team server — a persistent instance running on an internal or cloud server, shared by the development team
  3. Plandex Cloud — the hosted version at app.plandex.ai, managed by the Plandex team (monitor only your LLM backends)

For self-hosted deployments (patterns 1 and 2), check that the server is reachable:

# Check the Plandex server health
curl http://your-plandex-host:8080/health

# Or HTTPS if TLS is configured
curl https://your-plandex-host:8080/health

Step 2: Monitor the Plandex Server Health Endpoint

The Plandex server exposes a health endpoint that confirms the server process is running and ready to accept client connections and process plan operations:

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: http://your-plandex-host:8080/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Label: Plandex server (/health).
  7. Click Save.

This monitor catches server process crashes, port binding failures, and cases where the server has become unresponsive to new connections while existing connections time out.

If you have deployed Plandex behind a reverse proxy (Nginx, Caddy) on a custom domain with HTTPS, update the URL to https://plandex.your-domain.com/health to match your actual endpoint.

Step 3: Monitor the Plandex Web Interface (if enabled)

Plandex can be accessed via a browser-based interface in addition to the CLI. If your team has this enabled on a shared server:

# Check web interface
curl http://your-plandex-host:8080
  1. Add Monitor → HTTP.
  2. URL: http://your-plandex-host:8080.
  3. Check interval: 2 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: Plandex.
  7. Label: Plandex web interface.
  8. Click Save.

A web interface monitor that passes while the API health monitor fails indicates the static file server is alive but the backend plan execution API has crashed — an important distinction when triaging developer reports of "Plandex isn't responding."

Step 4: Monitor the Anthropic API (for Claude models)

Plandex defaults to using Claude for plan generation and code editing tasks, as Claude's long context window and instruction-following capability align well with multi-file plan execution. Monitor the Anthropic API directly:

curl -I https://api.anthropic.com
  1. Add Monitor → HTTP.
  2. URL: https://api.anthropic.com.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Label: Anthropic API (Plandex backend).
  7. Click Save.

An Anthropic API outage causes Plandex to fail at the first LLM call within any plan step — the plan state is preserved on the server but no progress can be made until the API recovers.

Step 5: Monitor the OpenAI API (for GPT-4 models)

Plandex supports OpenAI models and any OpenAI-compatible API. If your team uses Plandex with GPT-4o or routes through an OpenAI-compatible gateway:

  1. Add Monitor → HTTP.
  2. URL: https://api.openai.com/v1/models.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Label: OpenAI API (Plandex backend).
  7. Click Save.

Plandex supports model role configuration — assigning different LLM models to different roles (planner, builder, verifier). If your configuration uses Anthropic for planning and OpenAI for code generation, both APIs are in the critical path and both should be monitored.

Step 6: Monitor an LLM Proxy or Gateway

Teams routing Plandex through a centralized LLM gateway (LiteLLM proxy, OpenRouter, or a corporate AI access layer) for API key management, cost control, or audit logging need to monitor the gateway as a single point of failure:

# LiteLLM proxy health
curl https://your-llm-proxy.example.com/health

# OpenRouter API
curl -I https://openrouter.ai/api/v1/models

For a LiteLLM proxy:

  1. Add Monitor → HTTP.
  2. URL: https://your-llm-proxy.example.com/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: healthy.
  7. Label: LLM proxy (Plandex gateway).
  8. Click Save.

A proxy failure blocks all Plandex LLM calls regardless of which underlying model is configured, making this a high-priority monitor.

Step 7: Monitor SSL Certificates

Self-hosted Plandex deployments with HTTPS must have valid TLS certificates. An expired certificate breaks both the CLI-to-server connection and browser-based access:

# Check TLS certificate expiry for the Plandex server
openssl s_client -connect plandex.your-domain.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -dates

For the Plandex server domain:

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

For the Anthropic API domain called by the Plandex server:

  1. Add Monitor → SSL Certificate.
  2. Domain: api.anthropic.com.
  3. Alert when expiry is within: 30 days.
  4. Click Save.

Step 8: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Plandex server /health | Non-200 or timeout | Server crashed; check process status and restart the plandex-server binary | | Plandex web interface | Non-200 or keyword missing | Static server down; check reverse proxy and server process | | Anthropic API | Non-200 or timeout | Claude-backed plan steps fail; check status.anthropic.com; in-progress plans paused | | OpenAI API | Non-200 or timeout | GPT-backed steps fail; check OpenAI status page | | LLM proxy | Non-200 or keyword missing | All LLM calls blocked; check proxy logs and restart if needed | | SSL certificate | < 30 days to expiry | plandex CLI TLS errors imminent; renew certificate proactively |

Alert routing: Send Plandex server alerts to the team hosting the shared server. LLM API alerts should go to a shared developer tools channel since every developer's in-progress plans are affected simultaneously. Include the Plandex server logs path in the runbook: plan state is durable on the server, so plans can be resumed after recovery without data loss.

Common Plandex Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Plandex server process OOM-killed | Health endpoint monitor fires; CLI connections refused | | Anthropic API outage mid-plan-execution | Anthropic API monitor fires; plan steps halt at LLM call | | LLM proxy cert expires (gRPC error from Plandex) | SSL monitor alerts 30 days before proxy TLS fails | | OpenAI quota exhausted (429 on all requests) | OpenAI API monitor catches persistent 429 responses | | Reverse proxy misconfigured after upgrade | Server health monitor fires; CLI returns connection error | | Plandex database (SQLite) disk full | Health endpoint monitor fires when server rejects new plans | | DNS failure for Plandex server domain | External URL monitor fires; CLI cannot resolve server host | | LLM gateway upgrade breaks auth (401 errors) | Proxy health monitor fires or API key rotation breaks requests |

Plandex's plan-based approach to AI coding tasks means interruptions are more costly than in single-shot tools — a mid-plan failure leaves changes in a partially applied state that requires manual review. Vigilmon's external monitoring catches the Plandex server and LLM backend failures that cause these interruptions, giving your team visibility to restore service quickly and confidently resume plans from where they left off.

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

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles