tutorial

Monitoring Pagure with Vigilmon: API Health, Web UI, Git Transport, SSH & Webhook Worker Checks

How to monitor Pagure (self-hosted Git forge) with Vigilmon — REST API health, web UI availability, git HTTP clone endpoint, SSH service, pagure-ci webhook worker, and SSL certificate alerting.

Pagure is a Python/Flask-based self-hosted Git forge developed by the Fedora Project. It provides repository hosting, pull request workflows, issue tracking, and a Pagure-CI webhook integration — all in a single self-managed stack. When Pagure goes down, developers lose access to code, the CI webhook pipeline stalls, and pull request reviews grind to a halt. Vigilmon gives you external visibility into every layer of a Pagure installation: the API, the web interface, git HTTP transport, SSH connectivity, the event source service, and SSL certificates.

What You'll Build

  • An HTTP monitor on Pagure's versioned REST API health endpoint
  • A web UI availability check that confirms the full Flask application is rendering
  • A git HTTP clone endpoint probe for transport-layer health
  • SSH port monitoring for key-based developer access
  • An event source service check for real-time UI updates
  • SSL certificate expiry alerting for your Pagure domain

Prerequisites

  • Pagure running (typically behind Apache or nginx, listening on port 443)
  • The Pagure event source service (pagure_eventsourced) running if real-time updates are needed
  • A free account at vigilmon.online

Step 1: Check Pagure's REST API Version Endpoint

Pagure exposes /api/0/version — an unauthenticated endpoint that returns the running Pagure version. It exercises the Flask application, the database connection, and the API routing layer all at once:

curl https://pagure.yourdomain.com/api/0/version
# {"version": "5.13.3"}

A non-200 response or connection refused indicates Pagure's Flask process has crashed, the WSGI worker pool is exhausted, or the database connection has been lost.

Step 2: Create the API Health Monitor in Vigilmon

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://pagure.yourdomain.com/api/0/version
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: version (matches the JSON response body).
  7. Label: Pagure API Health
  8. Click Save.

This single monitor catches:

  • Pagure WSGI process crashes or OOM kills
  • Database connection failures (Pagure returns 500 when SQLAlchemy loses the DB)
  • Apache/nginx reverse proxy failures upstream of the Python application
  • DNS resolution errors on your Pagure domain

Step 3: Monitor the Web UI Availability

The API endpoint only exercises the JSON response path. Add a separate monitor for the Pagure homepage to verify the full template rendering stack, session store, and static asset routing:

  1. Add Monitor → HTTP.
  2. URL: https://pagure.yourdomain.com/
  3. Expected status: 200.
  4. Keyword: Pagure (present in the page <title> tag).
  5. Check interval: 120 seconds.
  6. Label: Pagure Web UI

If the API check passes but the web UI check fails, the failure is isolated to Pagure's Jinja2 template rendering or the Celery task that populates the dashboard feed.

Step 4: Verify the Git HTTP Clone Endpoint

Pagure serves git over HTTPS using the git-http-backend CGI bridge. Developers running git clone https://pagure.yourdomain.com/username/repo.git depend on this path. Probe the git-upload-pack info endpoint to verify transport health independently of the web UI:

curl -I "https://pagure.yourdomain.com/username/repo.git/info/refs?service=git-upload-pack"
# HTTP/2 401  — confirms transport is alive (auth required for private repos)
# HTTP/2 200  — for public repositories

A 401 or 200 both confirm the git HTTP transport is functional. A 502, 404, or connection refused means the CGI bridge or the underlying git binary path is broken.

  1. Add Monitor → HTTP.
  2. URL: https://pagure.yourdomain.com/username/repo.git/info/refs?service=git-upload-pack
    (replace username/repo with any known public repository)
  3. Expected status: 401 (or 200 for a public repo).
  4. Check interval: 300 seconds.
  5. Label: Pagure Git HTTP Transport

Step 5: Monitor the SSH Service Port

Most developers authenticate with SSH keys and use git@pagure.yourdomain.com:username/repo.git clone URLs. The SSH daemon can fail or have its authorized_keys configuration corrupted independently from the web stack. Add a TCP port check:

  1. Add Monitor → Port/TCP.
  2. Host: pagure.yourdomain.com
  3. Port: 22 (or your configured SSH port).
  4. Check interval: 120 seconds.
  5. Response timeout: 10 seconds.
  6. Label: Pagure SSH Access

An SSH port failure while the web UI is healthy indicates the SSH daemon has been stopped, firewall rules changed, or the ~/.ssh/authorized_keys file Pagure manages has been corrupted.

Step 6: Check the Pagure Event Source Service

Pagure's real-time web UI updates (pull request comments appearing without page reload, issue status changes) depend on a separate pagure_eventsourced process running on port 8080 by default. If this service crashes, the web UI still works but developers lose live update notifications.

  1. Add Monitor → HTTP.
  2. URL: http://pagure.yourdomain.com:8080/
    (or your configured eventsource port; keep it HTTP unless you've proxied it)
  3. Expected status: 200 (the eventsource service returns a minimal response).
  4. Check interval: 300 seconds.
  5. Label: Pagure Event Source Service

Step 7: Monitor Your SSL Certificate

A lapsed SSL certificate blocks all HTTPS-based git operations and web UI access. Pagure typically runs behind Apache or nginx with a Let's Encrypt certificate:

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

Let's Encrypt certificates expire every 90 days. The 30-day threshold gives you enough runway to fix certbot auto-renewal failures before developers are blocked.

Step 8: Heartbeat Monitor for the Pagure Worker (Celery)

Pagure uses Celery workers (pagure_worker) to process asynchronous tasks: sending email notifications, updating pull request merge status, and running webhook deliveries. Add a cron heartbeat to verify the worker is running:

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

if systemctl is-active --quiet pagure_worker; then
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
fi

In Vigilmon:

  1. Add Monitor → Heartbeat.
  2. Expected interval: 5 minutes.
  3. Grace period: 15 minutes.
  4. Label: Pagure Celery Worker

When the Celery worker crashes, email notifications stop, webhook deliveries queue up indefinitely, and pull request merge checks freeze — the heartbeat catches this before developers notice.

Common Pagure Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Pagure WSGI process OOM-killed | API health check fails within 60 s | | Database connection lost | API returns 500; API monitor alerts | | Apache/nginx proxy misconfigured | Web UI check fails | | SSH daemon stopped or firewall changed | SSH TCP port monitor fires | | Let's Encrypt renewal failure | SSL monitor alerts at 30 days | | Git HTTP backend (CGI) broken after upgrade | HTTP transport check returns 502 | | Event source service crash (live updates lost) | Event source monitor fires | | Celery worker stopped (notifications frozen) | Heartbeat stops; alert fires | | DNS failure after server migration | All monitors fire simultaneously |

Pagure is built for teams that want a self-managed Git forge with strong Fedora/Red Hat tooling integration, but self-managed means no one else is watching it. A Vigilmon setup covering the API, web UI, git transport, SSH, event source, SSL, and Celery worker gives you complete external visibility before your developers hit a wall.

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

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles