Monitoring Wolfi Container Workloads with Vigilmon

Wolfi is not a traditional Linux distribution. It is an "undistro" — a minimal, purpose-built base for container images designed by Chainguard with supply chain security as the first principle, not an afterthought. Wolfi images have no shell, no package manager cruft, and every package is signed and accompanied by a machine-readable SBOM. This makes Wolfi images dramatically smaller and more auditable than standard distro bases — but it also means your monitoring strategy needs to be just as deliberate. Vigilmon gives Wolfi-based workloads the runtime observability their minimal footprint demands: HTTP health checks, TCP port probes, cron heartbeats for non-HTTP services, and SSL certificate alerts.

What You'll Set Up

• HTTP health endpoint monitors for containerized services built on Wolfi
• TCP port probes to confirm services are accepting connections
• Cron heartbeat monitors for batch workloads and scheduled builds
• SSL certificate expiry alerts for externally exposed endpoints
• Alert channels so downtime reaches your team immediately

Prerequisites

• At least one running container built on a Wolfi or Chainguard base image
• The container is deployed and reachable over HTTP/HTTPS or a TCP port
• A free Vigilmon account

Step 1: Add a Health Endpoint to Your Wolfi Container

Because Wolfi images have no shell or extra tooling by default, your application binary is responsible for exposing a health endpoint. The pattern is the same regardless of language — add a lightweight /health or /healthz route to your application:

Go (net/http)

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"status":"ok"}`))
})

Python (FastAPI)

@app.get("/healthz")
def health():
    return {"status": "ok"}

Node.js (Express)

app.get('/healthz', (req, res) => {
  res.json({ status: 'ok', uptime: process.uptime() });
});

Because Wolfi is glibc-compatible, your existing binaries will run unchanged — only the base layer is different. Rebuild your image on the Wolfi base and verify the health endpoint responds before continuing:

# Build with Wolfi base
docker build -t myapp:wolfi .

# Run and probe locally
docker run -d -p 8080:8080 myapp:wolfi
curl -sf http://localhost:8080/healthz

Step 2: Create an HTTP Uptime Monitor in Vigilmon

With your Wolfi container running and the health endpoint confirmed, add a monitor in Vigilmon:

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

Vigilmon probes the endpoint every minute from multiple locations. If two consecutive checks fail, you receive an alert. Because Wolfi containers boot fast (small image, no init overhead), alert-on-two-failures is the right threshold — it avoids false positives from rolling restarts while still catching real outages within two minutes.

For microservices behind a load balancer, monitor both the load balancer endpoint and one representative pod endpoint if you have direct pod access. This distinguishes routing failures from application failures.

Step 3: TCP Port Monitoring for Non-HTTP Services

Not every Wolfi workload serves HTTP. Database sidecars, gRPC services, and message queue clients often expose only TCP ports. Vigilmon can probe those directly:

1. Click Add Monitor → TCP Port.
2. Enter your hostname and the port number (e.g. mygrpc.internal:9090).
3. Set Check interval to 1 minute.
4. Click Save.

A TCP probe confirms the process is listening and the network path is open, without requiring the full application stack to respond to an HTTP request. This is especially useful for Wolfi-based distroless images where you cannot exec into the container to run netcat manually — the TCP monitor becomes your only automated connectivity check.

Common Wolfi service ports to monitor:

| Service | Port | |---|---| | gRPC | 9090 | | Prometheus metrics | 9091 | | etcd | 2379, 2380 | | Redis | 6379 | | PostgreSQL sidecar | 5432 |

Step 4: SSL Certificate Alerts for Exposed Endpoints

Wolfi workloads are frequently deployed as microservices behind TLS-terminating ingress controllers or service meshes. Even with automated certificate rotation, expiry-related outages happen when rotation pipelines silently fail.

Add an SSL monitor to any HTTPS endpoint you created in Step 2:

1. Open the HTTP monitor for your service.
2. Enable Monitor SSL certificate under the SSL section.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

For services using mTLS between pods (common in Istio or Linkerd meshes running Wolfi workloads), also monitor your internal CA certificate if it is externally accessible. A 21-day window is sufficient for both Let's Encrypt (90-day) and internal CA certificates (1-year or longer).

Step 5: Heartbeat Monitoring for Build Pipelines and Batch Jobs

Wolfi's Melange build system and apko image builder are often run on a schedule — nightly security rebuilds, weekly SBOM refreshes, or triggered by upstream Wolfi package updates. These build jobs have no HTTP endpoint to probe, so use Vigilmon's cron heartbeat.

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set Expected ping interval to match your build schedule (e.g. 1440 minutes for a daily build).
3. Copy the heartbeat URL.

Add the ping at the end of your build script:

#!/bin/bash
set -e

# Build the Wolfi-based image
melange build packages.yaml --arch x86_64,arm64
apko build apko.yaml myapp:latest myapp.tar

# Push to registry
crane push myapp.tar registry.example.com/myapp:latest

# Signal success to Vigilmon
curl -s https://vigilmon.online/heartbeat/YOUR_ID

If the build fails at any step (set -e), the script exits before reaching curl, and Vigilmon alerts after the expected interval passes without a ping. This catches build failures, upstream Wolfi package pull failures, and registry push errors — all without any manual check.

For GitHub Actions workflows that build and push Wolfi images:

- name: Ping Vigilmon heartbeat
  if: success()
  run: curl -s https://vigilmon.online/heartbeat/YOUR_ID

The if: success() condition ensures the ping only fires on successful runs.

Step 6: Configure Alert Channels and Escalation

1. Go to Alert Channels in Vigilmon and add your preferred channel — Slack, email, PagerDuty, or a webhook.
2. Set Consecutive failures before alert to 2 for HTTP and TCP monitors. Wolfi containers restart in seconds, and a single probe miss during a rolling update should not page your team.
3. Use Maintenance windows before intentional redeployments to suppress alerts during expected downtime.

For security-sensitive Wolfi workloads, consider routing SBOM-related heartbeat alerts to a separate channel from uptime alerts — your security team may need to investigate a failed nightly SBOM refresh even when the production service itself is healthy.

Step 7: Multi-Container Visibility

Production Wolfi deployments typically include multiple containers — application, sidecar proxy, init containers, and ephemeral debug containers. Add a Vigilmon monitor for each critical service path:

https://api.yourdomain.com/healthz          → main API
https://api.yourdomain.com/metrics          → Prometheus metrics endpoint
grpc.internal:9090                          → gRPC service (TCP)
https://api.yourdomain.com (SSL check)      → certificate expiry
Heartbeat: /heartbeat/BUILD_ID              → nightly image rebuild

Vigilmon's status page lets you group these monitors under a single project, giving you a single pane of glass across all components of a Wolfi-based service.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP health check | /healthz on your service | Container crash, app errors, OOM kill | | TCP port probe | gRPC or sidecar port | Network policy block, process crash | | SSL certificate | HTTPS endpoint | Certificate rotation failure | | Cron heartbeat | Build pipeline script | Failed nightly Wolfi rebuild, SBOM miss |

Wolfi gives you a smaller attack surface and a verifiable supply chain — but those guarantees only cover what ships in the image. What happens after the container starts is your responsibility. Vigilmon watches the runtime: health endpoints, ports, certificates, and scheduled jobs. Together, Wolfi's build-time security and Vigilmon's runtime monitoring cover the full lifecycle of a hardened container workload.