Monitoring Werf with Vigilmon: CI Pipeline Health, Registry Availability, Deployment Heartbeats & SSL Certificates

Werf is Flant's open-source GitOps CI/CD tool that brings deterministic, content-addressed image building, Helm-based deployment, and automatic cleanup of stale registry images into a single pipeline. Engineering teams use Werf to ship applications to Kubernetes with confidence that every deployment is reproducible from source to cluster. When the container registry Werf publishes to becomes unavailable, or when a deployment pipeline silently stalls, your Kubernetes workloads run stale images and rollbacks become unreliable. Vigilmon gives you external visibility into your Werf pipeline's critical dependencies — registry availability, Kubernetes API reachability, and SSL certificate validity — so you know your GitOps delivery chain is healthy between deployments.

What You'll Build

• An HTTP monitor on your container registry health endpoint
• A TCP monitor confirming the registry port is reachable
• Heartbeat monitors verifying Werf deployment pipelines are completing successfully
• SSL certificate monitoring for your registry and deployment domain
• Alerting runbook mapped to Werf pipeline failure modes

Prerequisites

• A running Werf-based CI/CD pipeline (GitLab CI, GitHub Actions, or Jenkins)
• A container registry accessible to Werf (Docker Hub, Harbor, ECR, GCR, or self-hosted)
• A free account at vigilmon.online

Step 1: Verify Container Registry Availability

Werf depends on your container registry for both pushing newly-built images and pulling them during deployment. Confirm your registry is accessible:

# For a self-hosted Harbor registry
curl -s https://registry.yourdomain.com/api/v2.0/health

# For a generic OCI registry (Docker Registry v2)
curl -s https://registry.yourdomain.com/v2/

# Test with werf directly
werf bundle download --repo registry.yourdomain.com/myapp

A healthy Harbor registry returns {"status":"healthy"}. A Docker Registry v2 returns {} with status 200.

Step 2: Create a Vigilmon HTTP Monitor for the Container Registry

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://registry.yourdomain.com/v2/ (or your registry health endpoint).
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Label: Container Registry (Werf).
7. Click Save.

Set alerts after 1 consecutive failure — when the registry is down, Werf cannot push new builds or pull images for Helm-triggered deployments, halting your entire GitOps pipeline.

Step 3: Monitor the Registry Port with TCP

The container registry listens on port 443 for HTTPS or port 5000 for plain HTTP in development. A firewall rule change, expired certificate, or network policy misconfiguration can make the port unreachable even if the registry service is running:

1. Add Monitor → TCP.
2. Host: registry.yourdomain.com.
3. Port: 443.
4. Check interval: 2 minutes.
5. Label: Registry Port (TCP 443).
6. Click Save.

TCP monitoring at the port level catches network-layer failures that an HTTP health check might miss if the health endpoint itself is behind a failing load balancer.

Step 4: Monitor Werf Deployment Pipeline Success via Heartbeat

Werf runs inside your CI pipeline (GitLab CI, GitHub Actions, etc.). The most reliable end-to-end health signal is whether your deployment pipeline is completing successfully on schedule. Set up a heartbeat that Werf pings at the end of each successful deployment run:

Step 4a — Create a Heartbeat monitor in Vigilmon:

1. Add Monitor → Heartbeat.
2. Name: Werf Deployment Pipeline.
3. Expected interval: set to match your deployment frequency (e.g., 24 hours for daily deployments, 1 hour for continuous delivery).
4. Grace period: 30 minutes.
5. Copy the generated ping URL (e.g., https://vigilmon.online/ping/abc123).

Step 4b — Add the Vigilmon ping to your Werf CI pipeline:

For GitLab CI (.gitlab-ci.yml):

deploy:
  stage: deploy
  script:
    - werf converge --repo registry.yourdomain.com/myapp
    - curl -fsS -m 10 https://vigilmon.online/ping/abc123
  only:
    - main

For GitHub Actions (.github/workflows/deploy.yml):

- name: Deploy with Werf
  run: werf converge --repo registry.yourdomain.com/myapp

- name: Ping Vigilmon heartbeat
  if: success()
  run: curl -fsS -m 10 https://vigilmon.online/ping/abc123

The if: success() guard ensures Vigilmon is only pinged when the full Werf deployment succeeds. A failed build, image push error, or Helm rollout failure will cause the ping to be skipped, and Vigilmon will alert after the grace period.

Step 5: Monitor the Werf Bundle Publish Heartbeat

For teams using werf bundle publish to create versioned deployment bundles that are later applied via werf bundle apply, monitor the bundle publishing stage separately from the apply stage. This lets you distinguish build/publish failures from deployment failures:

Step 5a — Create a Heartbeat monitor in Vigilmon:

1. Add Monitor → Heartbeat.
2. Name: Werf Bundle Publish.
3. Expected interval: matches your publish schedule.
4. Grace period: 20 minutes.
5. Copy the ping URL.

Step 5b — Add to your publish pipeline:

publish:
  stage: publish
  script:
    - werf bundle publish --repo registry.yourdomain.com/myapp
    - curl -fsS -m 10 https://vigilmon.online/ping/abc123
  only:
    - tags

Separate heartbeats for publish and apply mean you can quickly distinguish "the image never got built and pushed" from "the deployment to the cluster failed."

Step 6: Monitor the Registry SSL Certificate

Werf uses TLS for all registry communication. An expired registry certificate will cause werf build and werf converge to fail immediately with a TLS handshake error, blocking all deployments:

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

Also monitor your Kubernetes ingress domain if Werf deploys a web application, since an expired application certificate breaks end-user access independently of pipeline health.

Step 7: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Registry HTTP health | Non-200 response | Check registry pod/service; verify storage backend | | Registry TCP port | Connection refused | Check firewall rules and ingress; verify TLS termination | | Deployment heartbeat | No ping within grace | Check CI pipeline logs; re-trigger deploy manually if blocked | | Bundle publish heartbeat | No ping within grace | Check build logs; verify registry credentials haven't rotated | | Registry SSL cert | < 30 days | Renew registry TLS certificate; verify cert-manager or ACME renewal |

Common Werf Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Container registry down | Registry HTTP and TCP monitors fire within 60–120 s | | Registry TLS cert expired | SSL monitor alerts at 30-day threshold; werf build fails with TLS error | | CI pipeline stalled (stuck job, quota hit) | Deployment heartbeat expires after grace period | | Registry credentials rotated but not updated in CI | Bundle publish heartbeat stops; werf exits non-zero | | Kubernetes API unavailable during werf converge | Deployment heartbeat stops; CI job fails | | OCI image layer push timeout | Bundle publish heartbeat stops on failed push | | Harbor storage backend full | Registry HTTP health returns non-200 |

Werf's reproducibility guarantees only hold when every component of the pipeline — the registry, the CI runner, and the cluster API — is operational. Vigilmon's external monitoring sits outside your CI infrastructure and independently confirms that your GitOps delivery chain is flowing, so a stalled pipeline or failing registry doesn't quietly leave your clusters running week-old images.

Start monitoring your Werf pipeline in under 5 minutes — register free at vigilmon.online.