Monitoring Cgit with Vigilmon: Web Interface, Repository Listing, Git HTTP Transport & SSL Checks

Cgit is an extremely fast, CGI-based web interface for browsing Git repositories — the same frontend used by the Linux kernel project and many large open-source organizations. Unlike full Git forges, Cgit is deliberately minimal: no accounts, no pull requests, just fast read-only browsing of Git repository contents served over HTTP. When Cgit goes down, developers lose access to the web browser for code exploration and the git HTTP clone endpoint stops working. Vigilmon gives you external visibility into Cgit's web interface, the repository listing page, git HTTP transport health, response time trends, and SSL certificate expiry.

What You'll Build

An HTTP monitor on the Cgit root page confirming the CGI process is alive
A repository listing page check that exercises the git object reading layer
A git HTTP clone endpoint probe for transport-layer health
Response time alerting to catch slow CGI spawn times before they escalate
SSL certificate expiry monitoring for your Cgit domain

Prerequisites

Cgit installed and running behind Apache or nginx (or lighttpd), typically on port 80/443
At least one Git repository configured in /etc/cgitrc or your cgit configuration
A free account at vigilmon.online

Step 1: Understand How Cgit Works

Cgit is a CGI application — each web request spawns a cgit process, which reads from bare Git repositories on disk and renders HTML. There is no persistent server process to crash; instead, failure modes include:

The web server (Apache/nginx) going down
The cgit CGI binary being missing or non-executable after a package update
Git repositories becoming inaccessible (permissions, filesystem mount failures)
The CGI process timing out on very large repositories

Because of this architecture, monitoring Cgit means monitoring the web server + CGI layer, the repository content layer, and the git HTTP transport.

Step 2: Monitor the Cgit Root Page

The Cgit root page lists all configured repositories. A 200 response with the expected content confirms the web server is running, the cgit binary is executable, and at least the configuration layer is intact:

curl -I https://git.yourdomain.com/
# HTTP/2 200

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://git.yourdomain.com/
Check interval: 60 seconds.
Response timeout: 10 seconds.
Expected status: 200.
Keyword: cgit (present in the default page title and footer).
Label: Cgit Web Interface
Click Save.

This monitor catches web server crashes, CGI binary permission issues, and any configuration that causes cgit to return a 500 error.

Step 3: Monitor the Repository Listing Page

The repository listing page (/ or a specific repository's summary page) requires Cgit to actually read from the Git objects on disk. Add a monitor that targets a specific known repository's summary page to confirm disk access is healthy:

Add Monitor → HTTP.
URL: https://git.yourdomain.com/repo-name/ (replace with a known repository name from your cgitrc)
Expected status: 200.
Keyword: summary (present in the repository summary page HTML).
Check interval: 120 seconds.
Label: Cgit Repository Access

If the root page check passes but this check fails, the problem is in disk access to that specific repository — permissions changed, the bare repo was corrupted, or the path in cgitrc is wrong.

Step 4: Verify the Git HTTP Clone Endpoint

Cgit can serve git over HTTP using the enable-http-clone=1 cgitrc option (which routes through git-http-backend). This allows developers to clone with git clone https://git.yourdomain.com/repo-name.git. Test the transport endpoint:

curl -I "https://git.yourdomain.com/repo-name.git/info/refs?service=git-upload-pack"
# HTTP/2 200  (for public repos with http-clone enabled)
# HTTP/2 401  (if authentication is required)

Add Monitor → HTTP.
URL: https://git.yourdomain.com/repo-name.git/info/refs?service=git-upload-pack
Expected status: 200 (or 401 if auth is required).
Check interval: 300 seconds.
Label: Cgit HTTP Clone Transport

If you haven't enabled enable-http-clone=1 in your cgitrc, this endpoint will return 403. Add that setting to allow HTTP cloning and then Vigilmon can verify it's working.

Step 5: Set Response Time Alerts for CGI Performance

Because Cgit spawns a new process for every HTTP request, response times are sensitive to server load. A slow response to the root page often signals the server is CPU-constrained or IO-starved from a large repository read. Configure response time thresholds on your root page monitor:

In the Cgit Web Interface monitor settings:

Open Response time alerts.
Warn at: 2 seconds (Cgit should be extremely fast under normal conditions).
Critical at: 5 seconds.

You can also add a targeted monitor for a large repository's log page, which is the most expensive Cgit operation:

Add Monitor → HTTP.
URL: https://git.yourdomain.com/repo-name/?h=main&q=&s=commit (the commit log view)
Response time warn: 2000 ms.
Label: Cgit Large Repo Log Latency

Sustained slow response times on the log page indicate the underlying Git repository has grown large enough that cgit's pack-file traversal is becoming expensive.

Step 6: Monitor Your SSL Certificate

A lapsed SSL certificate blocks all HTTPS access to the Cgit interface and all git clone https://... operations. Cgit deployments typically use Let's Encrypt certificates managed by Certbot:

Add Monitor → SSL Certificate.
Domain: git.yourdomain.com
Alert when expiry is within: 30 days.
Alert again: 14 days, 7 days, 3 days.

Since Cgit is often deployed on servers that may not have automatic Certbot renewal configured (many Cgit installations are on older servers), the 30-day advance warning is especially important.

Step 7: Disk Health Heartbeat for Repository Storage

Cgit reads directly from bare Git repositories on disk. When the disk fills up, the repositories can't receive new pushes (if you're using Cgit alongside a push-capable system like gitolite), and Cgit itself may log errors reading pack files. Set up a cron heartbeat to verify disk health:

#!/bin/bash
# /etc/cron.d/cgit-disk-heartbeat — runs every 5 minutes

DISK_USAGE=$(df /var/lib/git --output=pcent | tail -1 | tr -d '% ')
if [ "$DISK_USAGE" -lt 85 ]; then
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
fi

Adjust /var/lib/git to wherever your bare repositories are stored.

In Vigilmon:

Add Monitor → Heartbeat.
Expected interval: 5 minutes.
Grace period: 15 minutes.
Label: Cgit Repository Storage Health

Common Cgit Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Web server (Apache/nginx) crashed | Root page check fails within 60 s | | CGI binary missing after package update | Root page returns 500; monitor alerts | | Repository disk mount failure | Repository access check fails | | Git HTTP clone transport disabled | HTTP transport check returns 403 | | Let's Encrypt certificate expired | SSL monitor alerts at 30 days | | Slow CGI spawn on overloaded server | Response time alert fires | | Disk full — packs unreadable | Disk heartbeat stops; alert fires | | DNS misconfiguration | All monitors fire simultaneously |

Cgit's extreme simplicity and speed make it the right choice for teams that need read-only repository browsing without the overhead of a full Git forge. That same simplicity means no built-in health monitoring. A Vigilmon setup covering the web interface, repository access, git HTTP transport, response times, SSL, and disk health gives you complete external visibility into every layer of a Cgit deployment.

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