tutorial

Monitoring OpenGist with Vigilmon: Web UI Availability, Health Endpoint, Gist Listing & Git Storage Heartbeat

How to monitor your self-hosted OpenGist instance with Vigilmon — web UI availability on port 6157, the /-/health endpoint, the gist listing to confirm database and template rendering, SSL certificate alerts, and a heartbeat to detect when the Git snippet storage backend becomes unavailable.

OpenGist is a self-hosted GitHub Gist alternative: developers paste code snippets, share them with a URL, and fork each other's work — all backed by real Git repositories on your filesystem. When your OpenGist instance goes down, internal tooling links break, shared configuration snippets become inaccessible, and teams lose their internal Pastebin equivalent mid-incident. Even worse, if the Git storage directory gets unmounted or permission-restricted without the Go HTTP server crashing, OpenGist may continue serving the UI while silently failing all Git operations. Vigilmon gives you external visibility into every layer: the web server, the health endpoint, the database and template rendering stack, SSL certificate expiry on your snippet-sharing domain, and the Git storage backend health.

What You'll Build

  • An HTTP monitor on the OpenGist web UI (port 6157) for basic server availability
  • An HTTP monitor on the /-/health endpoint for application and database health
  • An HTTP monitor on the gist listing endpoint to confirm the database query and template rendering stack
  • An SSL certificate monitor for HTTPS-proxied OpenGist deployments
  • A heartbeat monitor to detect when the Git storage backend becomes unavailable

Prerequisites

  • OpenGist running on your server (default port 6157 — binary or Docker)
  • A domain or IP:port accessible from the internet
  • A free account at vigilmon.online

Step 1: Check the OpenGist Health Endpoint

OpenGist exposes a /-/health endpoint that returns an HTTP 200 and a health status response confirming the application is running and the database connection is healthy:

curl http://opengist.yourdomain.com:6157/-/health
# HTTP/1.1 200 OK
# {"status":"ok"}

A 200 response confirms the Go HTTP server is running, the application has initialized, and the database (SQLite or PostgreSQL) is accessible. A non-200 response or connection refused indicates OpenGist has crashed or the database connection has failed.

Step 2: Create the Health Endpoint Monitor in Vigilmon

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://opengist.yourdomain.com/-/health
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok (matches the health response body).
  7. Label: OpenGist Health
  8. Click Save.

This monitor catches:

  • Go process crashes or OOM kills on the server
  • SQLite database file corruption or lock contention (SQLite under concurrent write load can hit lock errors)
  • PostgreSQL connection pool exhaustion when switching from SQLite to Postgres at scale
  • Startup failures due to misconfigured environment variables or missing directories

Step 3: Monitor the OpenGist Web UI

The health endpoint confirms the application layer but doesn't test the full HTTP routing and template rendering stack. A check on the root path (/) or the public gist explore endpoint confirms the web server is serving pages to end users:

curl -I http://opengist.yourdomain.com:6157/
# HTTP/1.1 200 OK
  1. Add Monitor → HTTP.
  2. URL: https://opengist.yourdomain.com/
  3. Expected status: 200.
  4. Keyword: OpenGist (present in the default page title).
  5. Check interval: 120 seconds.
  6. Label: OpenGist Web UI
  7. Click Save.

If the health check passes but the web UI fails, the problem is in Go's HTTP routing layer or the HTML template rendering — useful for catching template parse errors that don't affect the health endpoint but break user-facing pages.

Step 4: Monitor the Gist Listing Endpoint

The /explore/gists endpoint (or / on instances that redirect to the public gist list) exercises the full stack: HTTP routing, database query, and Go template rendering. A 200 response here confirms OpenGist can retrieve gists from the database and render them:

curl -I http://opengist.yourdomain.com:6157/explore/gists
# HTTP/1.1 200 OK

For instances with authentication required for all pages, use the explore endpoint or an authenticated API call:

# Public gist listing (works on instances with public access enabled)
curl http://opengist.yourdomain.com:6157/explore/gists
  1. Add Monitor → HTTP.
  2. URL: https://opengist.yourdomain.com/explore/gists
  3. Expected status: 200.
  4. Keyword: gist (present in the page content or HTML).
  5. Check interval: 120 seconds.
  6. Label: OpenGist Gist Listing
  7. Click Save.

This check is most valuable for catching database query failures that are silent at the health endpoint level — a partial database corruption where the health check table is accessible but the gist content tables are not.

Step 5: Monitor Your SSL Certificate

OpenGist is typically reverse-proxied behind nginx, Caddy, or Traefik for HTTPS termination. When the certificate on your snippet-sharing domain expires, all shared snippet URLs return TLS errors — teams can no longer access shared configuration files or code snippets:

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

Let's Encrypt certificates on reverse-proxy hosts require certbot or Caddy ACME to auto-renew. If the renewal cron job fails silently, the 30-day alert gives you time to investigate and manually renew before snippet URLs stop working.

Step 6: Heartbeat Monitor for Git Storage Backend

OpenGist stores each gist as a bare Git repository on the filesystem under its configured opengist.datadir (default: ~/.opengist/repos/ or the path set in config.yml). If this directory gets unmounted, its permissions change, or the disk fills up, OpenGist's web server continues running and the health endpoint returns 200 — but all Git operations (clone, push, view raw content, fork) silently fail. Users see gist pages that load but show no content or return errors when cloning.

Set up a server-side heartbeat that pings Vigilmon only when the Git storage directory is writable:

#!/bin/bash
# /etc/cron.d/opengist-git-storage-heartbeat — runs every 5 minutes

# Adjust this to your OpenGist data directory
GIT_STORAGE_DIR="${HOME}/.opengist/repos"

# Check that the directory is mounted and writable
if [ -d "$GIT_STORAGE_DIR" ] && [ -w "$GIT_STORAGE_DIR" ]; then
  # Also check disk usage — warn if over 85% full
  DISK_USED_PCT=$(df "$GIT_STORAGE_DIR" --output=pcent | tail -1 | tr -d '% ')
  if [ "$DISK_USED_PCT" -lt 85 ]; then
    curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
  fi
fi

In Vigilmon:

  1. Add Monitor → Heartbeat.
  2. Expected interval: 5 minutes.
  3. Grace period: 15 minutes.
  4. Label: OpenGist Git Storage

For OpenGist instances with an active user base, extend the check to verify via the API that gists are accessible:

# Requires an API token — generate one in OpenGist settings
OPENGIST_TOKEN="your-api-token"
RESPONSE=$(curl -fsS -H "Authorization: token $OPENGIST_TOKEN" \
  http://localhost:6157/api/v1/gists 2>/dev/null)

# Check for a valid JSON array response
GIST_COUNT=$(echo "$RESPONSE" | python3 -c "import sys,json; d=json.load(sys.stdin); print(len(d))" 2>/dev/null)

if [ -n "$GIST_COUNT" ] && [ -d "$GIT_STORAGE_DIR" ] && [ -w "$GIT_STORAGE_DIR" ]; then
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
fi

When the Git storage directory becomes unavailable, the heartbeat stops and Vigilmon alerts you — before users discover their shared snippets are inaccessible.

Common OpenGist Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Go process crash or OOM kill | Health endpoint returns connection refused; alert fires within 60 s | | SQLite database lock contention or corruption | Health endpoint returns non-200; gist listing also fails | | PostgreSQL connection pool exhausted | Health endpoint returns error; database queries fail | | Git storage directory unmounted or permission-changed | Web UI and health endpoint return 200; Git storage heartbeat stops | | Disk full on Git storage volume | Git storage heartbeat disk check fails; ping stops | | nginx/Caddy reverse proxy misconfiguration | All external monitors fail; Go server may still be running on port 6157 | | Let's Encrypt certificate expires on snippet domain | SSL monitor alerts at 30 days before expiry | | Template rendering error (bad Go template syntax after update) | Web UI check fails; health endpoint may still return 200 | | OAuth misconfiguration (GitHub/GitLab login broken) | Login redirect fails; catchable with keyword check for error message |

OpenGist earns developer trust by being simple and reliable — but self-hosted simplicity means no one else is watching your instance. Vigilmon's external monitoring covers the full stack: health endpoint, web UI, gist listing, SSL certificate, and Git storage availability — so when something breaks, you know before your team's shared snippets go dark.

Start monitoring OpenGist 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