tutorial

Monitoring Nexus Repository Manager with Vigilmon: Web UI, REST API Health, Writable Status & Blob Store Disk Alerts

How to monitor Sonatype Nexus Repository Manager with Vigilmon — web UI availability on port 8081, REST API status endpoint, writable node check, blob store disk usage heartbeat, and SSL certificate alerts for HTTPS-proxied Nexus deployments.

Sonatype Nexus Repository Manager is the most widely deployed self-hosted artifact repository — serving Maven, npm, Docker, PyPI, Helm, RubyGems, Go, NuGet, Apt, Yum, and Conda packages from a single server. When Nexus goes down, CI/CD pipelines stall waiting for artifact downloads, Docker builds fail because images can't be pulled from the internal registry, and developers lose access to proxied dependencies from Maven Central, npm, or PyPI. Vigilmon gives you external visibility into every layer of a Nexus installation: the web UI, the REST API health, the writable node status, SSL certificate expiry, and blob store disk pressure before uploads start failing with 500 errors.

What You'll Build

  • An HTTP monitor on Nexus's REST API status endpoint (/service/rest/v1/status)
  • A full system health check via the /service/rest/v1/status/check endpoint
  • A writable node status check to distinguish primary from read-only passive nodes
  • A web UI availability check on port 8081
  • SSL certificate monitoring for HTTPS-proxied Nexus deployments
  • A blob store disk usage heartbeat to catch storage pressure before uploads fail

Prerequisites

  • Nexus Repository Manager running (OSS or Pro, typically on port 8081)
  • A domain or IP:port accessible externally
  • A free account at vigilmon.online

Step 1: Check the Nexus REST API Status Endpoint

Nexus exposes /service/rest/v1/status — an unauthenticated endpoint that returns the edition and version of the running server:

curl http://nexus.yourdomain.com:8081/service/rest/v1/status
# {"edition":"OSS","version":"3.63.0-01"}

A 200 response confirms the Java Jetty server is running and the REST API layer is responding. A connection refused or 503 means Nexus has crashed or is still initializing.

Step 2: Create the REST API Health Monitor in Vigilmon

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://nexus.yourdomain.com/service/rest/v1/status
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds (Nexus startup can be slow under load).
  5. Expected status: 200.
  6. Keyword: edition (matches the JSON response body).
  7. Label: Nexus API Status
  8. Click Save.

This monitor catches:

  • Nexus JVM process crashes or out-of-memory kills
  • OrientDB or H2 database failures that prevent the REST API from responding
  • Java heap exhaustion causing Nexus to become unresponsive
  • Reverse proxy misconfigurations dropping traffic to port 8081

Step 3: Add the Full System Health Check

The /service/rest/v1/status/check endpoint goes deeper — it confirms both blob store accessibility and database health:

curl http://nexus.yourdomain.com:8081/service/rest/v1/status/check
# {"available":true,"healthy":true}

A healthy: false response means Nexus is partially running but one of its subsystems (database, blob store, or scheduler) has detected a problem. Add a second monitor:

  1. Add Monitor → HTTP.
  2. URL: https://nexus.yourdomain.com/service/rest/v1/status/check
  3. Expected status: 200.
  4. Keyword: "healthy":true (confirms full system health).
  5. Check interval: 120 seconds.
  6. Label: Nexus System Health

If the API Status monitor passes but this check fails, a Nexus subsystem (typically the blob store or scheduler thread) has detected an internal problem — the server is running but degraded.

Step 4: Monitor the Writable Node Status

In a Nexus HA-C (high-availability clustered) deployment, only the primary node accepts artifact uploads. Passive nodes are read-only. The /service/rest/v1/status/writable endpoint confirms whether your node can accept writes:

curl http://nexus.yourdomain.com:8081/service/rest/v1/status/writable
# HTTP 200 → node is writable (primary or standalone)
# HTTP 503 → node is read-only (passive in HA-C cluster)
  1. Add Monitor → HTTP.
  2. URL: https://nexus.yourdomain.com/service/rest/v1/status/writable
  3. Expected status: 200.
  4. Check interval: 120 seconds.
  5. Label: Nexus Writable Status

An unexpected 503 on what should be your primary node means it has failed over to read-only mode — artifact uploads from CI/CD will fail with 503 while reads continue. This monitor catches that split-brain scenario before your build team notices.

Step 5: Monitor the Nexus Web UI

The API endpoints don't exercise the full Nexus UI stack. A separate check on the root path confirms the embedded Jetty server is serving the web application:

curl -I http://nexus.yourdomain.com:8081/
# HTTP/1.1 200 OK
  1. Add Monitor → HTTP.
  2. URL: https://nexus.yourdomain.com/
  3. Expected status: 200.
  4. Keyword: Nexus (present in the HTML page title).
  5. Check interval: 300 seconds.
  6. Label: Nexus Web UI

If the API status checks pass but the web UI fails, the problem is in Nexus's frontend servlet layer rather than a total JVM crash.

Step 6: Monitor Your SSL Certificate

Nexus is typically deployed behind nginx or Apache for HTTPS termination (or using its own built-in HTTPS via keystore). When the certificate expires, every client connecting to your Nexus instance — Maven, npm, Docker daemon, pip — fails with TLS errors:

  1. Add Monitor → SSL Certificate.
  2. Domain: nexus.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 time to debug certbot renewal failures before pipelines break.

Step 7: Blob Store Disk Usage Heartbeat

Nexus blob stores hold all artifact binaries. When a blob store runs out of disk space, all artifact uploads fail immediately with 500 Internal Server Error while artifact reads (downloads) continue normally — making the failure non-obvious from the outside. OS disk metrics alone are insufficient because Nexus may store blobs on a mounted volume separate from the root filesystem.

Set up a server-side script that pings Vigilmon only when blob store disk is healthy:

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

# Path to your Nexus blob store directory (adjust to your installation)
BLOBSTORE_PATH="/nexus-data/blobs"

# Calculate available disk percentage
DISK_AVAIL_PCT=$(df "$BLOBSTORE_PATH" --output=pcent | tail -1 | tr -d '% ')
DISK_USED_PCT=$((100 - DISK_AVAIL_PCT))

# Only ping heartbeat if blob store disk is below 80% used
if [ "$DISK_USED_PCT" -lt 80 ]; 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: Nexus Blob Store Disk

When blob store disk usage exceeds 80%, the heartbeat stops firing and Vigilmon alerts you — before CI/CD pipelines start receiving 500 errors on artifact publish steps.

For more detailed blob store metrics, Nexus Pro exposes /service/rest/v1/blobstores (authenticated) which returns availableSpaceInBytes and blobCount per store:

curl -u admin:password \
  https://nexus.yourdomain.com/service/rest/v1/blobstores
# [{"name":"default","type":"File","availableSpaceInBytes":107374182400,...}]

You can extend the heartbeat script to check the API response and alert when any blob store drops below a configured threshold rather than relying solely on OS df output.

Common Nexus Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Nexus JVM OOM-killed or crashed | API Status returns connection refused; alert fires within 60 s | | OrientDB/H2 database corruption | System Health check returns healthy: false | | Primary node failed over to read-only | Writable Status returns 503; alert fires | | nginx reverse proxy drops port 8081 routing | Web UI check fails while server is up | | Blob store disk full — uploads return 500 | Blob store heartbeat stops; alert fires before users notice | | Let's Encrypt certificate expires | SSL monitor alerts at 30 days | | Nexus startup stuck (JVM initializing) | API Status returns 503 or timeout | | Scheduler thread deadlock (partial degradation) | System Health returns healthy: false | | DNS change breaks client connections | All monitors fire simultaneously |

Nexus is a critical piece of infrastructure in any mature CI/CD pipeline — but it runs as a single JVM with significant disk and memory requirements that make it prone to silent degradation. A Vigilmon setup covering the API, system health, writable status, web UI, SSL, and blob store disk gives you external visibility into every failure mode before builds start failing.

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