tutorial

Monitoring Reposilite with Vigilmon: Web UI, Health API, Maven Artifact Resolution & Proxy Repository Heartbeat

How to monitor Reposilite (lightweight self-hosted Maven repository) with Vigilmon — web UI availability on port 8080, health API endpoint, Maven artifact resolution check, SSL certificate alerts, and a heartbeat for the Maven Central proxy to catch outbound connectivity failures before Gradle/Maven builds break.

Reposilite is the lightweight, resource-efficient alternative to Nexus and Artifactory for teams that need private Maven and Gradle artifact hosting without the operational complexity of a full-blown enterprise repository manager. Built on Kotlin and Vert.x, it runs comfortably on a small VPS and supports hosted repositories, Maven Central proxying, token-based authentication, and a built-in web UI — all in a single binary. When Reposilite goes down or its Maven Central proxy breaks, Gradle and Maven builds that depend on uncached dependencies fail with resolution errors, blocking development and CI/CD pipelines. Vigilmon gives you external visibility into Reposilite's web UI, health API, Maven artifact resolution, SSL certificate expiry, and the outbound proxy connection to Maven Central — catching failures before your builds break.

What You'll Build

  • An HTTP monitor on Reposilite's web UI (port 8080)
  • A health API endpoint check confirming the application health status
  • A Maven artifact resolution check for a known hosted artifact
  • SSL certificate monitoring for HTTPS Reposilite deployments
  • A Maven Central proxy heartbeat to detect outbound connectivity failures

Prerequisites

  • Reposilite running (typically on port 8080 or behind a reverse proxy)
  • At least one hosted repository configured with a test artifact, or a proxy to Maven Central
  • A domain or IP:port accessible externally
  • A free account at vigilmon.online

Step 1: Check the Reposilite Web UI

Reposilite serves both the web interface and Maven repository on the same port (8080 by default). A GET request to the root path returns the web UI — confirming the Kotlin/Vert.x HTTP server is running:

curl http://repo.yourdomain.com:8080/
# Returns the Reposilite web application HTML

A 200 response confirms the server is up and serving. A connection refused means the Reposilite process has crashed, the JVM has exited, or the configured port is unreachable.

Step 2: Create the Web UI Monitor in Vigilmon

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://repo.yourdomain.com/
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: Reposilite (present in the HTML page title).
  7. Label: Reposilite Web UI
  8. Click Save.

This monitor catches:

  • Reposilite JVM process crashes or OOM kills
  • Vert.x HTTP server failures
  • Port binding failures after a restart
  • Reverse proxy routing failures to port 8080

Step 3: Check the Reposilite Health API

Reposilite exposes a health endpoint at /api/health that returns the application health status in JSON format:

curl https://repo.yourdomain.com/api/health
# {"status":"UP"}

A 200 response with "status":"UP" confirms that the Reposilite application layer — including its storage backend and internal scheduler — is functioning correctly. This endpoint is more reliable than the web UI check for detecting partial failures where the HTTP server is running but the repository layer is degraded.

  1. Add Monitor → HTTP.
  2. URL: https://repo.yourdomain.com/api/health
  3. Expected status: 200.
  4. Keyword: UP (confirms the application health status).
  5. Check interval: 60 seconds.
  6. Label: Reposilite Health API

If the web UI check passes but the health API returns a non-UP status, Reposilite's internal application state has a problem — typically a storage layer issue or a failed background task — while the HTTP layer continues to serve static content.

Step 4: Monitor Maven Artifact Resolution

The definitive test of a Maven repository is whether it serves Maven artifacts correctly. Probe a known artifact's POM file or maven-metadata.xml to confirm the entire repository serving stack — HTTP layer, storage backend, and Maven protocol handling — is operational:

# For a hosted repository — probe a known artifact POM:
curl https://repo.yourdomain.com/releases/com/example/my-library/1.0.0/my-library-1.0.0.pom
# Returns the POM XML

# For the Maven metadata of an artifact group:
curl https://repo.yourdomain.com/releases/com/example/my-library/maven-metadata.xml
# Returns maven-metadata.xml with version list

Replace releases with your repository name, and com/example/my-library with a real artifact from your hosted repository.

  1. Add Monitor → HTTP.
  2. URL: https://repo.yourdomain.com/releases/com/example/my-library/maven-metadata.xml
  3. Expected status: 200.
  4. Keyword: metadata (present in valid maven-metadata.xml content).
  5. Check interval: 300 seconds.
  6. Label: Reposilite Maven Resolution

If the health API passes but Maven artifact resolution fails, the problem is in the repository serving layer — permissions, storage path configuration, or a corrupted repository index — rather than a total process failure.

Step 5: Monitor Your SSL Certificate

Reposilite deployments are typically reverse-proxied via nginx or Caddy for HTTPS termination, or configured with built-in HTTPS using a keystore. When the TLS certificate expires, Gradle and Maven builds fail immediately with SSL certificate errors:

Could not resolve com.example:my-library:1.0.0.
   > Could not HEAD 'https://repo.yourdomain.com/releases/com/example/my-library/1.0.0/my-library-1.0.0.pom'.
      > PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed
  1. Add Monitor → SSL Certificate.
  2. Domain: repo.yourdomain.com
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days.

Gradle and Maven clients — and the JVM TLS stack — are particularly strict about certificate validity and will fail immediately on any certificate issue, making SSL expiry one of the most impactful failure modes for a Maven repository.

Step 6: Maven Central Proxy Repository Heartbeat

One of Reposilite's most valuable features is its ability to proxy Maven Central, allowing developers to resolve org.apache.commons:commons-lang3 and other public dependencies through your private Reposilite instance rather than directly from the internet. This provides caching, audit logging, and dependency governance.

When Reposilite's outbound connection to Maven Central breaks — due to network policy changes, DNS failures, firewall rule modifications, or Maven Central itself having issues — builds that depend on uncached (or evicted) dependencies fail with resolution errors. The Reposilite health endpoint and web UI check will both show green because Reposilite itself is fine; only the proxy is broken.

Verify the proxy by fetching a known, stable dependency through Reposilite's proxy repository:

curl -I \
  https://repo.yourdomain.com/central/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.pom
# HTTP/2 200 → proxy to Maven Central is working
# HTTP/2 502 or connection refused → proxy is broken

Replace central with your configured Maven Central proxy repository name in Reposilite.

Set up a server-side heartbeat that pings Vigilmon only when the proxy resolves successfully:

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

RESPONSE_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
  https://repo.yourdomain.com/central/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.pom)

if [ "$RESPONSE_CODE" = "200" ]; 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: Reposilite Maven Central Proxy

When the proxy connection to Maven Central fails, the heartbeat stops pinging and Vigilmon alerts you — before developers start reporting mysterious build failures for dependencies that "used to work fine."

You can also configure a direct HTTP monitor on the proxy artifact URL:

  1. Add Monitor → HTTP.
  2. URL: https://repo.yourdomain.com/central/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.pom
  3. Expected status: 200.
  4. Keyword: project (present in valid Maven POM XML).
  5. Check interval: 300 seconds.
  6. Label: Reposilite Proxy Check

Common Reposilite Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Reposilite JVM OOM-killed or crashed | Web UI returns connection refused; alert within 60 s | | Vert.x HTTP server failure | Health API returns non-200 | | Repository storage path permission issue | Health API shows degraded; Maven resolution returns 404 | | Reverse proxy drops port 8080 routing | Web UI check fails while process is running | | Maven Central proxy connection broken | Proxy heartbeat stops; alert fires before builds fail | | Let's Encrypt certificate expires | SSL monitor alerts at 30 days | | Artifact POM missing or corrupted | Maven resolution check returns non-200 or wrong keyword | | Network policy change blocks outbound to Maven Central | Proxy heartbeat stops; direct health checks still pass | | DNS change breaks client connections | All monitors fire simultaneously | | Reposilite token auth misconfiguration | Maven resolution returns 401; alert fires |

Reposilite's lightweight footprint makes it easy to run, but that also means there's no managed infrastructure layer watching over it. A Vigilmon setup covering the web UI, health API, Maven artifact resolution, SSL, and the Maven Central proxy gives you complete external visibility into every failure mode — from a JVM crash to a silent outbound proxy failure — before your development team's Gradle builds start failing.

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