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

Helios is a distributed tracing and observability platform built on OpenTelemetry that gives engineering teams automatic instrumentation, root cause analysis, and real-time flow visualization for microservice architectures. Its API server is the central hub that ingests spans from every instrumented service, stores trace data, and serves the UI and integration endpoints — if it goes down, trace collection halts silently across the entire fleet. Vigilmon provides the external vantage point that Helios cannot provide for itself: continuous uptime and latency checks from outside your infrastructure that keep watching even when the observability platform is the component that has failed. You can add your first monitor for free, no credit card required.

Why Helios needs external monitoring

API server crash stops span ingestion across all services. Helios accepts spans from OpenTelemetry SDKs via its ingestion endpoint. When the API server crashes or becomes unreachable, every instrumented service's exporter begins buffering spans in memory. Once those buffers fill, spans are silently dropped. Because the failure is in the observability layer itself, no trace alert fires, engineers lose visibility into production behavior, and the outage goes undetected until someone notices missing data in the UI.
Database connectivity loss returns empty trace results without errors. Helios stores trace data in a backend database. If connectivity to that database is interrupted, trace queries return empty result sets rather than errors. Engineers investigating a latency spike find no traces for the affected time window and may incorrectly conclude that no traffic was processed — a misleading signal that can delay incident response. An external HTTP monitor that validates response body content detects this state immediately.
TLS certificate expiry breaks SDK exporters silently. OpenTelemetry exporters are typically configured with strict TLS validation. When the Helios ingestion endpoint's certificate expires, all SDK exporters begin failing with TLS errors and buffering spans. The failure appears to each service as a transient exporter issue, not a platform outage, so no centralized alert fires. An external SSL and HTTP monitor catches the expiry before it takes down trace collection.
Memory pressure causes the trace processor to OOM-kill mid-batch. The Helios trace processor holds batches of incoming spans in memory before writing them to storage. Under traffic spikes, the process can exhaust available memory and be killed by the OS. The process restarts but the in-flight batch is lost, leaving gaps in trace timelines. Kubernetes readiness probes may lag several seconds behind the restart, during which external requests receive connection refused — something only an external monitor can detect reliably.
UI serving failures hide from backend health checks. Helios runs its web UI on the same host as the API server but may serve it from a separate process or port. A crash in the static asset server or a misconfigured reverse proxy leaves the API ingestion path healthy while every engineer who opens the dashboard sees a blank page or 502. Internal health checks that only probe the ingestion endpoint miss this class of failure entirely.

What you'll need

A running Helios instance with its API server accessible over HTTPS
The public hostname or IP for your Helios deployment, for example https://helios.example.com
A free Vigilmon account — monitors start running in under a minute with no credit card required

Step 1: Expose Helios's health endpoint

Verify your Helios installation is reachable and locate the health endpoint before configuring Vigilmon monitors.

# Check Helios API server health endpoint
curl -I https://helios.example.com/api/health

# Sample output:
# HTTP/2 200
# content-type: application/json
# x-helios-version: 1.4.2

# Verify the ingestion endpoint is accepting spans
curl -s -o /dev/null -w "%{http_code}" \
  -X POST https://helios.example.com/v1/traces \
  -H "Content-Type: application/json" \
  -d '{"resourceSpans":[]}'
# Expected: 200

# Check the UI endpoint
curl -I https://helios.example.com/
# Expected: HTTP/2 200

If Helios is running behind a reverse proxy (nginx, Caddy, Traefik), confirm the proxy is forwarding the /api/health path correctly:

# nginx config snippet — ensure the health path is proxied
cat /etc/nginx/sites-enabled/helios.conf

# Expected block:
# location /api/health {
#     proxy_pass http://127.0.0.1:4318;
#     proxy_set_header Host $host;
# }

# Test from the proxy layer
curl -v https://helios.example.com/api/health 2>&1 | grep -E "< HTTP|< x-helios"

If you are running Helios in Docker, confirm the container is healthy and the port is exposed:

# Check container status
docker ps --filter name=helios --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

# Sample output:
# NAMES            STATUS          PORTS
# helios-server    Up 2 days       0.0.0.0:4318->4318/tcp, 0.0.0.0:3000->3000/tcp

# Test health inside the container
docker exec helios-server curl -s http://localhost:4318/api/health

Step 2: Set up HTTP monitoring in Vigilmon

Add an HTTP monitor for the Helios health endpoint:

Log in to vigilmon.online and click Add Monitor.
Set Monitor type to HTTP.
Enter the URL: https://helios.example.com/api/health
Set Check interval to 60 seconds and Expected status code to 200.
Click Save Monitor — Vigilmon will run the first check within a minute.

Add a monitor for the Helios ingestion endpoint

The ingestion endpoint is the most critical path — a failure here means trace data stops flowing:

Click Add Monitor again.
Set Monitor type to HTTP.
Enter the URL: https://helios.example.com/v1/traces
Set Method to POST, Expected status code to 200, and Timeout to 10 seconds.
Add a Request body of {"resourceSpans":[]} and set Content-Type header to application/json.
Click Save Monitor.

Why external monitoring catches what internal checks miss

Helios relies on receiving data from your services to surface problems — but that creates a monitoring blind spot: when Helios itself fails, your traces stop flowing and nothing inside the observability stack fires an alert. Vigilmon operates entirely outside your infrastructure, sending real HTTP requests from external nodes on a fixed interval. It detects TLS failures, DNS misconfiguration, load balancer degradation, and application crashes that are completely invisible to health checks running inside the same cluster. Because Vigilmon does not depend on Helios to generate its alerts, it is the only reliable way to know when your tracing platform is down.

Step 3: Monitor Helios's TCP port

A TCP monitor confirms that the Helios server is accepting connections at the network layer before TLS or HTTP processing begins. This catches scenarios where the process has crashed but the port is still listed as open by the OS, or where a load balancer is terminating connections without forwarding them.

In Vigilmon, click Add Monitor.
Set Monitor type to TCP.
Enter Host: helios.example.com and Port: 443.
Set Check interval to 60 seconds.
Click Save Monitor.

If your Helios instance uses a non-standard port for the API server, add a second TCP monitor for that port:

# Find the ports Helios is listening on
ss -tlnp | grep helios
# or
docker inspect helios-server | jq '.[0].NetworkSettings.Ports'

# Sample output:
# {
#   "4318/tcp": [{"HostIp": "0.0.0.0", "HostPort": "4318"}],
#   "3000/tcp": [{"HostIp": "0.0.0.0", "HostPort": "3000"}]
# }

Add a TCP monitor for port 4318 (OTLP gRPC/HTTP) and port 3000 (UI) separately to isolate which layer has failed when an alert fires.

Step 4: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels and click Add Channel.
Choose Email and enter the address that should receive notifications (for example, platform-team@example.com or an on-call distribution list).
Assign this channel to all Helios monitors created in Steps 2 and 3.
Click Save — Vigilmon will send a test email to confirm delivery.

Webhook alerts

For Slack, PagerDuty, or an internal incident management system, add a webhook channel:

In Alert Channels, click Add Channel and choose Webhook.
Paste your endpoint URL (a Slack incoming webhook, PagerDuty Events API v2 endpoint, or custom URL).
Vigilmon will POST the following JSON payload when a monitor transitions to down:

{
  "monitor_id": "mon_helios_api_health",
  "monitor_name": "Helios API /api/health",
  "status": "down",
  "previous_status": "up",
  "checked_at": "2026-07-12T09:14:22Z",
  "response_time_ms": null,
  "status_code": null,
  "error": "Connection refused",
  "url": "https://helios.example.com/api/health"
}

Assign all Helios monitors to this channel and click Save.

Runbook: diagnostics to run when an alert fires

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

echo "=== Container status ==="
docker ps --filter name=helios --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

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

echo "=== Health endpoint response ==="
curl -sv https://helios.example.com/api/health 2>&1 | tail -20

echo "=== Port connectivity ==="
nc -zv helios.example.com 443
nc -zv helios.example.com 4318

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

echo "=== System memory ==="
free -h

echo "=== Disk usage ==="
df -h /var/lib/helios

Step 5: Create a public status page

A Vigilmon status page gives your engineering team and any teams that depend on distributed tracing a single URL to check Helios health during incidents — no cluster access required.

In Vigilmon, navigate to Status Pages and click New Status Page.
Give it a name such as Helios Tracing Platform and choose a subdomain like helios-status.vigilmon.page.
Add all monitors created in this tutorial: the /api/health HTTP monitor, the /v1/traces ingestion monitor, and the TCP port monitor.
Optionally add a description explaining which services depend on Helios for trace data.
Click Publish — the page is immediately accessible and updates in real time.

Share this URL in your team's incident response runbook and link it from your internal developer documentation so engineers know where to look when traces stop appearing.

Putting it all together

| Monitor | Type | What it catches | |---|---|---| | https://helios.example.com/api/health | HTTP | API server crash, process OOM kill, reverse proxy misconfiguration, TLS expiry | | https://helios.example.com/v1/traces | HTTP | Ingestion endpoint failure, database connectivity loss, span processing errors | | helios.example.com:443 | TCP | Network-level connectivity loss, load balancer failure, port exhaustion |

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

# 1. Is the Helios container running?
docker ps --filter name=helios

# 2. Are there recent errors in the API server?
docker logs helios-server --tail 50 --since 5m

# 3. Can the health endpoint be reached?
curl -sf https://helios.example.com/api/health || echo "Health check FAILED"

# 4. Is the ingestion port open?
nc -zv helios.example.com 4318 && echo "Port open" || echo "Port CLOSED"

# 5. How long until the TLS cert expires?
echo | openssl s_client -connect helios.example.com:443 \
  -servername helios.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

# 6. Is the database connection healthy?
docker exec helios-server curl -s http://localhost:4318/api/health | jq '.database'

What's next

SSL certificate monitoring — Vigilmon can alert you days before the TLS certificate on helios.example.com expires, giving you time to renew before SDK exporters begin failing silently. Add an SSL monitor pointing at the same hostname.
Heartbeat monitoring for trace pipeline continuity — Configure a cron job in your CI/CD pipeline to send a synthetic trace to Helios every few minutes and POST a heartbeat to a Vigilmon dead-man's-switch endpoint after successful ingestion. If the pipeline stops sending heartbeats, Vigilmon fires an alert that does not depend on the Helios stack.
Latency trend monitoring — Use Vigilmon's response time history to establish a latency baseline for the /api/health and /v1/traces endpoints. Sudden latency increases often precede full outages and give you time to scale or restart the service before trace collection is interrupted.

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