Gitness Monitoring with Vigilmon: CI/CD Pipeline, API Health & Git Service Uptime

Your developers push code to your self-hosted Gitness instance, expecting their CI pipeline to kick off automatically. Nothing happens. Forty minutes later, someone checks the UI — the web app returns a 504. Pipelines are stuck in queue. The Git push succeeded, but the runner service died two hours ago and nobody noticed.

Gitness is an open-source CI/CD and code hosting platform by Harness — a self-hosted alternative to GitHub, GitLab, and Drone CI combined. Teams use it for Git hosting, pull request workflows, and automated build pipelines. When Gitness goes down, code review stops and deployments stall. Vigilmon gives you the external monitor that catches Gitness failures before they block your engineering team.

This tutorial walks you through monitoring Gitness end-to-end with Vigilmon.

What You'll Build

• A Vigilmon HTTP monitor on the Gitness web UI
• An API health monitor using Gitness's /api/v1/health endpoint
• A pipeline runner service health check
• An SSL certificate expiry alert
• A Git repository endpoint availability check

Prerequisites

• A self-hosted Gitness instance (Docker or Kubernetes)
• A free account at vigilmon.online

Step 1: Monitor the Gitness Web UI

The Gitness web interface is what developers interact with daily. A misconfigured reverse proxy, a frontend container crash, or a failed upgrade can leave users unable to open pull requests or browse repositories.

Test it:

curl -I https://gitness.your-domain.com/

Expected response:

HTTP/2 200
content-type: text/html; charset=utf-8

Set up the Vigilmon monitor:

1. Log in to Vigilmon and click New Monitor → HTTP.
2. Set URL to https://gitness.your-domain.com/.
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Under Advanced → Keyword check, add:
   • Keyword present: "Gitness" (or your organization name)
6. Save.

Vigilmon polls the Gitness UI every minute from multiple global regions.

Step 2: Monitor the Gitness API Health Endpoint

Gitness exposes a dedicated health check endpoint at /api/v1/health. This endpoint verifies that the core API server is responsive and connected to its database. It's the most reliable single signal for overall Gitness backend health.

Test it:

curl https://gitness.your-domain.com/api/v1/health

Expected response:

{
  "status": "ok"
}

A non-200 response or a missing status field means the backend API is unavailable — even if the static web UI still loads from cache.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://gitness.your-domain.com/api/v1/health.
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Under Advanced → JSON body assertion, add:
   • Path: status
   • Operator: equals
   • Value: ok
6. Save.

Step 3: Pipeline Runner Service Health

Gitness's CI pipelines are executed by one or more runner services — separate processes that poll the Gitness server for pending pipeline jobs and execute them. When the runner crashes, queued pipelines never start and no error is visible to developers unless they dig into logs.

The Gitness runner exposes a lightweight HTTP health endpoint when configured:

curl http://gitness-runner.your-domain.com:3000/healthz

Expected response:

{
  "status": "ok"
}

If your runner is not configured to expose a health port, monitor it indirectly by querying the Gitness API for runner registration:

curl -H "Authorization: Bearer <your-api-token>" \
  https://gitness.your-domain.com/api/v1/runners

Expected response:

[
  {
    "id": 1,
    "name": "default-runner",
    "online": true
  }
]

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://gitness-runner.your-domain.com:3000/healthz (or the runners API endpoint).
3. Set Check interval to 2 minutes.
4. Set Expected status code to 200.
5. Under Advanced → JSON body assertion, add:
   • Path: status
   • Operator: equals
   • Value: ok
6. Save.

Step 4: SSL Certificate Monitoring

Gitness is typically served over HTTPS with Let's Encrypt or internal CA certificates. Certificate expiry is a silent failure — developers get browser security warnings and Git push/pull operations over HTTPS break entirely.

Vigilmon tracks SSL certificate expiry on all HTTPS monitors. Add a dedicated check:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://gitness.your-domain.com/.
3. Under Advanced → SSL certificate, enable Alert when certificate expires within 14 days.
4. Save.

You'll get a warning two weeks before expiry — enough time to renew before your team hits a certificate error.

Step 5: Git Repository Endpoint Check

Gitness serves Git repositories over HTTPS using the standard Git smart HTTP protocol. A broken repository endpoint means git clone, git push, and git pull all fail — even when the web UI appears healthy. This commonly happens when the internal Git service is misconfigured or when storage mounts become unavailable.

Test a repository's Git info endpoint:

curl -I https://gitness.your-domain.com/<org>/<repo>.git/info/refs?service=git-upload-pack

Expected response:

HTTP/2 401
www-authenticate: Basic realm="Gitness"

A 401 Unauthorized is the correct response for an unauthenticated Git probe — it confirms the Git HTTP service is alive and routing correctly.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://gitness.your-domain.com/<org>/<repo>.git/info/refs?service=git-upload-pack.
3. Set Check interval to 5 minutes.
4. Set Expected status code to 401.
5. Save.

Replace <org>/<repo> with a real, non-empty repository in your Gitness instance.

Step 6: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

• Email — immediate alerts to your DevOps or platform team
• Webhook — post to Slack, Discord, or PagerDuty

A Slack alert when Gitness's health endpoint fails:

🔴 DOWN: gitness.your-domain.com/api/v1/health
Status: 503 Service Unavailable
Region: US-East
Triggered: 2026-04-02 14:23 UTC

Recovery:

✅ RECOVERED: gitness.your-domain.com/api/v1/health
Downtime: 14 minutes

Step 7: Status Page

Go to Status Pages → New Status Page in Vigilmon. Add all five Gitness monitors and publish the page. Share it with your engineering team so they can check platform status without filing a support ticket:

<a href="https://vigilmon.online/status/<your-slug>">
  <img src="https://vigilmon.online/badge/<monitor-slug>" alt="Gitness Status" />
</a>

What You've Built

| Scenario | How Vigilmon catches it | |---|---| | Gitness web UI crash or proxy failure | HTTP monitor detects non-200 on homepage | | Backend API failure or DB disconnect | /api/v1/health returns non-200 or status != ok | | Pipeline runner crash (CI jobs stuck in queue) | Runner health endpoint returns non-200 | | SSL certificate expired or not renewed | Certificate monitor fires 14 days before expiry | | Git HTTP service broken (clone/push fails) | Repository info endpoint returns non-401 | | DNS misconfiguration | HTTP monitor detects DNS resolution failure | | Storage mount failure (repo files unavailable) | Git endpoint returns 500 instead of 401 |

Gitness brings integrated code hosting and CI/CD to self-hosted teams — but that also means you carry the reliability responsibility. Vigilmon gives you the external monitoring layer that your Gitness dashboard can't provide.

Start monitoring Gitness today — register free at vigilmon.online.