tutorial

How to Monitor Digma with Vigilmon (HTTP + TCP + Alerts)

Digma is a continuous feedback platform for developers that connects to OpenTelemetry-compatible observability backends and surfaces performance insights, re...

Digma is a continuous feedback platform for developers that connects to OpenTelemetry-compatible observability backends and surfaces performance insights, regressions, and anomalies directly inside the IDE. Its backend service processes incoming trace data, runs the AI-powered analysis engine, and exposes the API that IDE plugins and CI integrations query for code-level insights. When the Digma backend goes down, developers lose live performance feedback during coding sessions, CI pipelines stop receiving regression data, and the analysis queue falls behind — all silently, because the failure is inside the observability toolchain itself. Vigilmon provides the external uptime and latency monitoring that Digma cannot provide for itself: independent checks from outside your infrastructure that keep watching even when the feedback platform has failed. You can add your first monitor for free, no credit card required.

Why Digma needs external monitoring

  • Backend outage silently halts IDE feedback for all developers. When the Digma backend API becomes unreachable, every developer's IDE plugin begins failing to fetch insights and eventually enters a degraded or disconnected state. Because the failure is in the tooling layer rather than in production services, no alert fires and developers simply stop receiving performance feedback — they may not notice until they are actively investigating a regression and find the Digma panel showing stale or empty data.

  • Analysis queue backlog causes stale insights without any visible error. Digma processes incoming trace data through an async analysis queue. If the queue processor falls behind — due to a spike in trace volume, a memory constraint, or a downstream database slowdown — insights served by the API reflect an increasingly outdated view of the codebase. The API continues to return HTTP 200 with data, but the data is hours or days stale. An external monitor that checks a timestamp field in the response body can detect this drift before it misleads engineers.

  • Database connectivity loss causes the API to return 500s intermittently. Digma stores code insights in a relational backend. Intermittent connectivity problems between the API server and its database can cause requests to succeed or fail depending on query timing, producing sporadic HTTP 500 responses that are easy to miss in logs. Vigilmon's continuous polling from external nodes builds a clear timeline of availability that internal dashboards — which typically sample at much lower rates — cannot provide.

  • Port conflicts after container restarts bind to wrong interfaces. Digma runs as a set of Docker containers. After a host reboot or Docker daemon restart, containers may start successfully but bind their ports to 127.0.0.1 instead of 0.0.0.0 if the port mapping configuration drifts. The containers appear healthy in docker ps, but all external traffic is refused. A TCP monitor catches this class of failure immediately because it tests actual network reachability, not just process status.

  • TLS or certificate expiry cuts off CI integration pipelines. Teams that integrate Digma into CI pipelines use HTTPS to send trace data and retrieve regression reports. A certificate expiry or TLS misconfiguration on the Digma server causes these pipelines to fail, often with misleading SSL error messages that engineers attribute to transient network issues. An external SSL and HTTP monitor with a pre-expiry alert gives the team days to renew before pipelines are disrupted.

What you'll need

  • A running Digma backend instance accessible over HTTPS or HTTP
  • The hostname or IP for your Digma server, for example https://digma.example.com
  • A free Vigilmon account — monitors start running in under a minute with no credit card required

Step 1: Expose Digma's health endpoint

Verify your Digma backend is running and locate the health endpoint before adding Vigilmon monitors.

# Check Digma API health endpoint
curl -I http://digma.example.com:5051/api/about

# Sample output:
# HTTP/2 200
# content-type: application/json
# x-digma-version: 0.3.25

# Inspect the response body for version and status fields
curl -s http://digma.example.com:5051/api/about | jq .

# Sample output:
# {
#   "applicationVersion": "0.3.25",
#   "deploymentType": "DockerCompose",
#   "isCentralize": true
# }

# Verify the analytics engine is accepting data
curl -I http://digma.example.com:5049/

# Sample output:
# HTTP/2 200
# content-type: text/plain; charset=utf-8

If Digma is running via Docker Compose, check the full service status:

# Check all Digma containers
docker compose -f /opt/digma/docker-compose.yml ps

# Sample output:
# NAME                   IMAGE                    STATUS          PORTS
# digma-api              digmaai/digma-api        Up 3 hours      0.0.0.0:5051->5051/tcp
# digma-analytics        digmaai/digma-analytics  Up 3 hours      0.0.0.0:5049->5049/tcp
# digma-db               postgres:14              Up 3 hours      5432/tcp
# digma-collector        digmaai/collector        Up 3 hours      0.0.0.0:5050->5050/tcp

# Test the OTLP collector endpoint
curl -s -o /dev/null -w "%{http_code}" \
  -X POST http://digma.example.com:5050/v1/traces \
  -H "Content-Type: application/json" \
  -d '{"resourceSpans":[]}'
# Expected: 200

Step 2: Set up HTTP monitoring in Vigilmon

Add an HTTP monitor for the Digma API health endpoint:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Monitor type to HTTP.
  3. Enter the URL: https://digma.example.com/api/about
  4. Set Check interval to 60 seconds and Expected status code to 200.
  5. Optionally add a Keyword match for applicationVersion to verify the response body is substantive.
  6. Click Save Monitor — Vigilmon will run the first check within a minute.

Add a monitor for the Digma analytics engine

The analytics engine is the component that processes traces and generates code insights. A failure here means all insight data becomes stale even if the API appears healthy:

  1. Click Add Monitor again.
  2. Set Monitor type to HTTP.
  3. Enter the URL: https://digma.example.com:5049/
  4. Set Expected status code to 200 and Timeout to 10 seconds.
  5. Click Save Monitor.

Why external monitoring catches what internal checks miss

Digma is designed to surface failures in your application code — but this creates a blind spot: when Digma itself fails, there is nothing inside the platform to generate an alert. Developers may lose IDE feedback for hours without realizing it, especially in teams that rely on Digma passively rather than actively querying it. Vigilmon polls the Digma API from external network nodes on a fixed schedule, independently of everything running inside your infrastructure. It detects process crashes, TLS failures, DNS outages, and database connectivity problems that internal health checks — running on the same host or in the same cluster — cannot reliably surface.

Step 3: Monitor Digma's TCP port

A TCP monitor confirms that the Digma API server is accepting network connections before any HTTP or TLS processing occurs. This catches scenarios where the container has started but the port is bound to the loopback interface, or where a firewall rule change has blocked external access.

  1. In Vigilmon, click Add Monitor.
  2. Set Monitor type to TCP.
  3. Enter Host: digma.example.com and Port: 5051.
  4. Set Check interval to 60 seconds.
  5. Click Save Monitor.

Add a second TCP monitor for the collector port used by IDE plugins and CI pipelines:

# Confirm the collector is listening
ss -tlnp | grep 5050
# or
docker port digma-collector 5050
# Expected: 0.0.0.0:5050

Create a Vigilmon TCP monitor for port 5050 (OTLP collector) to independently verify that developers' IDEs can reach the trace ingestion endpoint.

Step 4: Configure alert channels

Email alerts

  1. In Vigilmon, go to Alert Channels and click Add Channel.
  2. Choose Email and enter the address for the team or individual responsible for the Digma deployment (for example, devex-team@example.com).
  3. Assign this channel to all Digma monitors created in Steps 2 and 3.
  4. Click Save — Vigilmon will send a test email to confirm delivery.

Webhook alerts

For Slack, PagerDuty, or your internal incident management system:

  1. In Alert Channels, click Add Channel and choose Webhook.
  2. Paste your endpoint URL (a Slack incoming webhook, PagerDuty Events API v2 endpoint, or custom receiver).
  3. Vigilmon will POST the following JSON payload when a monitor transitions to down:
{
  "monitor_id": "mon_digma_api_about",
  "monitor_name": "Digma API /api/about",
  "status": "down",
  "previous_status": "up",
  "checked_at": "2026-07-12T11:08:43Z",
  "response_time_ms": null,
  "status_code": null,
  "error": "Connection refused",
  "url": "https://digma.example.com/api/about"
}
  1. Assign all Digma monitors to this channel and click Save.

Runbook: diagnostics to run when an alert fires

#!/bin/bash
# Digma alert runbook — run these in order when Vigilmon fires

echo "=== Container status ==="
docker compose -f /opt/digma/docker-compose.yml ps

echo "=== API server logs (last 100 lines) ==="
docker logs digma-api --tail 100

echo "=== Analytics engine logs ==="
docker logs digma-analytics --tail 50

echo "=== Health endpoint response ==="
curl -sv http://digma.example.com:5051/api/about 2>&1 | tail -20

echo "=== Port connectivity ==="
nc -zv digma.example.com 5051 && echo "API port open" || echo "API port CLOSED"
nc -zv digma.example.com 5050 && echo "Collector port open" || echo "Collector port CLOSED"

echo "=== Database connectivity ==="
docker exec digma-db pg_isready -U digma

echo "=== Memory usage ==="
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"

echo "=== TLS certificate expiry ==="
echo | openssl s_client -connect digma.example.com:443 \
  -servername digma.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Step 5: Create a public status page

A Vigilmon status page gives your developer experience team and all developers who depend on Digma a single URL to check platform health during incidents without needing server access.

  1. In Vigilmon, navigate to Status Pages and click New Status Page.
  2. Give it a name such as Digma Developer Feedback Platform and choose a subdomain like digma-status.vigilmon.page.
  3. Add all monitors created in this tutorial: the /api/about HTTP monitor, the analytics engine monitor, and the TCP port monitors.
  4. Optionally add a description noting that Digma provides IDE performance insights and CI regression feedback.
  5. Click Publish — the page is immediately accessible and updates in real time.

Share this URL in your developer documentation so engineers know where to check when their IDE plugin shows stale or missing data.

Putting it all together

| Monitor | Type | What it catches | |---|---|---| | https://digma.example.com/api/about | HTTP | API server crash, database connectivity failure, application startup error | | https://digma.example.com:5049/ | HTTP | Analytics engine crash, insight processing failure, queue processor outage | | digma.example.com:5051 | TCP | Network-level API unreachability, port binding errors, firewall changes | | digma.example.com:5050 | TCP | Collector unreachability for IDE plugins and CI pipelines |

# Quick-reference diagnostic one-liners when a Vigilmon alert fires

# 1. Are all Digma containers running?
docker compose -f /opt/digma/docker-compose.yml ps

# 2. Are there recent errors in the API?
docker logs digma-api --tail 50 --since 5m | grep -i "error\|exception\|fatal"

# 3. Can the API endpoint be reached?
curl -sf http://digma.example.com:5051/api/about || echo "API check FAILED"

# 4. Is the database accepting connections?
docker exec digma-db pg_isready -U digma && echo "DB ready" || echo "DB UNAVAILABLE"

# 5. Is the collector port open to external traffic?
nc -zv digma.example.com 5050 && echo "Collector reachable" || echo "Collector UNREACHABLE"

# 6. What is the analytics engine status?
curl -sf http://digma.example.com:5049/ || echo "Analytics engine FAILED"

What's next

  • SSL certificate monitoring — If your Digma deployment uses TLS (recommended for production), add a Vigilmon SSL monitor to alert you days before the certificate expires and before IDE plugins begin rejecting connections.
  • CI pipeline heartbeat — Configure your CI pipeline to POST a heartbeat to a Vigilmon dead-man's-switch endpoint after each successful Digma analysis job. If the pipeline stops sending heartbeats — because Digma became unreachable or the analysis failed — Vigilmon fires an alert that does not depend on the Digma stack being healthy.
  • Response latency trending — Track Vigilmon's response time history for the /api/about endpoint to establish a baseline. Latency increases in the API often indicate growing analysis queue depth or database connection pool exhaustion, allowing you to scale before the platform becomes unresponsive.

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.

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