Monitoring Harness CD with Vigilmon: API Health, Delegate Connectivity, Pipeline Trigger Endpoint & SSL Certificate Alerts

Harness CD is the continuous delivery platform that orchestrates deployments across cloud providers, Kubernetes clusters, and on-premises environments — coordinating artifact promotion, canary rollouts, and approval gates at enterprise scale. When Harness's API gateway goes down, engineers cannot trigger pipelines, approve deployments, or roll back failed releases. When Harness Delegates lose connectivity to the control plane, all pipeline executions stall silently because the agent that runs actual deployment tasks can no longer communicate with the orchestration layer. Vigilmon gives you external visibility into every layer of Harness CD: the API health endpoint, web UI availability, pipeline trigger endpoint, delegate webhook, and SSL certificate expiry.

What You'll Build

A monitor on Harness's API health endpoint to detect control plane failures
A web UI availability check confirming the Harness dashboard is accessible
A pipeline trigger endpoint check to verify webhook-driven deployments can fire
An SSL certificate monitor for your Harness domain or self-hosted instance
An alerting setup that isolates API failures from UI and pipeline trigger issues

Prerequisites

A Harness CD account (SaaS at app.harness.io or a self-hosted Harness installation)
At least one deployed Harness Delegate with outbound connectivity to the Harness control plane
A free account at vigilmon.online

Step 1: Understand Harness CD's Health Endpoints

For Harness SaaS, the control plane exposes health endpoints under the gateway service. You can verify API availability with:

curl https://app.harness.io/api/health
# Returns: {"resource":{"status":"HEALTHY",...}}

For a self-hosted Harness installation, the gateway container exposes:

curl https://harness.example.com/api/health
# Returns HTTP 200 with a JSON status payload

A healthy response returns HTTP 200 with a JSON body containing "status":"HEALTHY". If the Harness gateway or manager service is unavailable, you receive a 502, 503, or a connection error from the load balancer in front of the installation.

Step 2: Create a Vigilmon HTTP Monitor for the API Health Endpoint

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://app.harness.io/api/health (or https://harness.example.com/api/health for self-hosted).
Check interval: 60 seconds.
Response timeout: 15 seconds.
Expected status: 200.
Keyword: HEALTHY (present in the JSON response body when all services are up).
Click Save.

This monitor catches:

Harness gateway process crashes or restarts
Manager service failures that prevent pipeline scheduling
Database connectivity issues that make the API unresponsive
Network or load balancer problems in front of the Harness control plane
Version upgrade failures that leave the API in a degraded state

Alert sensitivity: Set to trigger after 1 consecutive failure. When the Harness API is down, no pipelines can be triggered, approved, or rolled back — and engineering teams lose their entire deployment capability.

Step 3: Monitor the Harness Web UI

The Harness web UI is the interface that DevOps engineers use to trigger pipeline runs, inspect execution logs, approve stages, and configure services and environments. A UI failure is distinct from an API failure — the Angular frontend can fail to load while the backend API is still responding:

curl https://app.harness.io
# Returns HTML with "Harness" in the page content

Add Monitor → HTTP.
URL: https://app.harness.io (or your self-hosted URL).
Check interval: 2 minutes.
Response timeout: 20 seconds.
Expected status: 200.
Keyword: Harness (appears in the page title and HTML content).
Label: Harness CD web UI.
Click Save.

When the UI monitor fires but the /api/health monitor is green, the problem is in the frontend serving layer — a CDN cache invalidation, a static asset build failure, or a content delivery problem — rather than a backend API outage. This lets you route the alert to frontend engineers rather than the entire platform team.

Step 4: Monitor the Pipeline Trigger Endpoint

Harness CD supports webhook-based pipeline triggers that allow external systems (GitHub, Jenkins, custom CI tools) to fire deployments automatically. The trigger endpoint is a REST API that accepts webhook payloads and schedules pipeline executions. If this endpoint is unreachable, all webhook-triggered deployments silently fail:

# Verify the trigger endpoint responds (a GET returns 405 Method Not Allowed, confirming the endpoint exists)
curl -I https://app.harness.io/gateway/pipeline/api/webhook/triggerProcessingDetails
# Returns: HTTP/2 405 (endpoint exists but requires POST with payload)

Add Monitor → HTTP.
URL: https://app.harness.io/gateway/pipeline/api/webhook/triggerProcessingDetails.
Check interval: 5 minutes.
Response timeout: 15 seconds.
Expected status: 405 (Method Not Allowed confirms the endpoint is reachable).
Label: Harness pipeline trigger endpoint.
Click Save.

Why 405? Monitoring a POST endpoint with a GET request returns 405 when the endpoint is healthy and properly routing requests, and a 502/503 when the gateway in front of it is down. This is a lightweight liveness check that avoids sending test payloads into the production pipeline scheduler.

Step 5: Monitor the Harness Delegate Gateway Connectivity

Harness Delegates are lightweight agents that run in your infrastructure (Kubernetes, VMs, Docker) and execute pipeline tasks on behalf of the Harness control plane. Delegates maintain a persistent outbound connection to the Harness SaaS endpoint:

# Verify delegate registration endpoint is reachable
curl https://app.harness.io/api/agent/capabilities
# Returns HTTP 200 or 401 (unauthorized) — both confirm the endpoint is up

Add Monitor → HTTP.
URL: https://app.harness.io/api/agent/capabilities.
Check interval: 2 minutes.
Response timeout: 10 seconds.
Expected statuses: 200 or 401 (both confirm the endpoint is reachable; 401 means the request was received but rejected without credentials).
Label: Harness delegate gateway.
Click Save.

Configure this monitor to accept 401 as a valid response: a 401 means the delegate gateway endpoint is operational and correctly requiring authentication. A 502 or 503 means the endpoint is unreachable.

Step 6: Monitor SSL Certificates

Harness CD communicates across TLS for every interaction — between the UI and the API gateway, between Delegates and the control plane, and between webhook senders and the trigger endpoint. Certificate expiry breaks all of these simultaneously:

openssl s_client -connect app.harness.io:443 2>/dev/null | openssl x509 -noout -dates

For self-hosted Harness:

openssl s_client -connect harness.example.com:443 2>/dev/null | openssl x509 -noout -dates

Add Monitor → SSL Certificate.
Domain: app.harness.io (or your self-hosted domain).
Alert when expiry is within: 30 days.
Alert again: 14 days, 7 days, 3 days, 1 day.
Click Save.

For self-hosted Harness installations managed by cert-manager, Let's Encrypt renewal can fail when ACME challenges are blocked by Kubernetes NetworkPolicies or when the ClusterIssuer hits rate limits after infrastructure changes. A 30-day alert window gives you time to investigate and renew before expiry impacts Delegate connectivity.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, set up alert channels for the Harness monitoring stack:

| Monitor | Trigger | Action | |---|---|---| | /api/health | Non-200 or HEALTHY missing | Check Harness manager and gateway services; review Harness status page | | Web UI | Non-200 or keyword missing | Frontend serving issue; check CDN or static asset deployment | | Pipeline trigger endpoint | Non-405 response | Gateway routing failure; pipelines triggered by webhooks will not fire | | Delegate gateway | Non-200/401 response | Delegates may lose connectivity; check Harness SaaS status | | SSL certificate | < 30 days to expiry | Renew certificate; expiry breaks both UI access and Delegate connectivity |

Alert after: 1 consecutive failure for the API health and pipeline trigger monitors. 2 consecutive failures for UI and SSL monitors.

Common Harness CD Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Harness SaaS control plane outage | All monitors fire; correlate with Harness status page | | Manager service crash | /api/health returns non-HEALTHY; pipelines cannot be scheduled | | UI frontend CDN failure | UI monitor fires; API health monitor stays green | | Pipeline trigger gateway down | Trigger endpoint monitor fires; webhook deployments stall silently | | Delegate loses outbound connectivity | Delegate gateway monitor fires; running pipelines time out | | SSL certificate expires on self-hosted | SSL monitor alerts; all connections fail including Delegate registration | | Harness upgrade breaks API | /api/health returns degraded or errors after version update | | Load balancer misconfiguration | All HTTP monitors fire simultaneously | | Database backend slow or unavailable | /api/health returns non-HEALTHY; API requests time out | | Network partition between Delegate and control plane | Delegate gateway monitor fires; tasks queued but not executed |

Harness CD is the deployment control plane for engineering organizations running at scale — when it fails, every team that relies on automated deployments loses the ability to ship. Vigilmon gives you external visibility across every failure surface: the API health endpoint, web UI, pipeline trigger gateway, delegate connectivity endpoint, and SSL certificate expiry, so you catch outages before engineers start reporting that their deployments are not moving.

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