Sonatype Nexus Repository Manager is the artifact proxy and store that sits between your CI/CD pipelines and the outside world. It caches Maven Central, npm, PyPI, and Docker Hub, and it hosts your internal private packages. When Nexus goes down, builds fail across every team — and because it usually sits behind a corporate firewall, developers may not realize the registry is the problem. Vigilmon gives you external uptime monitoring for Nexus: health checks, service availability monitoring, SSL certificate alerts, and background task heartbeats.
What You'll Set Up
- HTTP uptime monitor for the Nexus REST API health endpoint
- Repository format-specific endpoint checks (npm, Maven, Docker)
- SSL certificate expiry alerts
- Cron heartbeat for Nexus scheduled cleanup tasks
- Alert channels for on-call notification
Prerequisites
- Sonatype Nexus Repository Manager 3.x (OSS or Pro)
- HTTPS configured on your Nexus instance
- A Nexus admin account for API-based verification
- A free Vigilmon account
Step 1: Monitor the Nexus REST API Health Endpoint
Nexus Repository Manager 3.x exposes a system status endpoint at /service/rest/v1/status that returns 200 OK when all core subsystems are healthy. This is the canonical liveness check.
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - Enter:
https://nexus.yourdomain.com/service/rest/v1/status - Set Check interval to
1 minute. - Set Expected HTTP status to
200. - Click Save.
Verify the endpoint manually:
curl -s https://nexus.yourdomain.com/service/rest/v1/status
# {"edition":"OSS","version":"3.x.x","state":"STARTED"}
When Nexus is starting up or in a degraded state, state changes from STARTED to STARTING or FAILED_OVER — and the HTTP status code changes to 503. Vigilmon will alert when the status code deviates from 200.
For a more detailed health check that includes writable storage verification:
curl -s https://nexus.yourdomain.com/service/rest/v1/status/writable
# Returns 200 when Nexus can write to its blob store; 503 if read-only
Add a second monitor targeting /service/rest/v1/status/writable to catch blob store failures where Nexus can serve artifacts but can't receive new ones — which would silently break CI publish steps.
Step 2: Monitor the Nexus Web UI
Nexus's web UI availability is separate from the API. Developers and DevOps engineers use the UI to browse components, manage repositories, and view security scan results. A Jetty or reverse proxy misconfiguration can take down the UI while the API remains functional.
- Click Add Monitor → HTTP / HTTPS.
- Enter:
https://nexus.yourdomain.com/ - Set Expected HTTP status to
200. - Set Check interval to
5 minutes. - Under Keyword matching, set Response body contains to
Nexus Repository Manager. - Click Save.
The keyword match confirms you're seeing the actual Nexus UI and not an nginx error page or a load balancer health stub returning 200.
Step 3: Monitor Repository Format Endpoints
Different artifact formats use different API endpoints. Monitor the ones your CI/CD pipelines rely on:
Maven (Central proxy or hosted):
# Verify: should return 200 with XML
curl -I https://nexus.yourdomain.com/repository/maven-central/
Add monitor: https://nexus.yourdomain.com/repository/maven-central/ → Expected: 200
npm (proxy or hosted):
# Verify: should return 200 with registry metadata
curl -s https://nexus.yourdomain.com/repository/npm-proxy/-/ping
# {}
Add monitor: https://nexus.yourdomain.com/repository/npm-proxy/-/ping → Expected: 200
Docker (hosted registry):
# Verify v2 API: should return 401
curl -I https://nexus.yourdomain.com/v2/
Add monitor: https://nexus.yourdomain.com/v2/ → Expected: 401
Create each as a separate Vigilmon HTTP monitor with a 5-minute check interval. Separate monitors let you pinpoint which format failed — a corrupted blob store for Docker images shouldn't show up as a Maven outage in your alerting.
Step 4: SSL Certificate Alerts
Nexus serves artifacts to every build agent, developer machine, and deployment pipeline in your organization. A certificate expiry causes TLS errors across all of them simultaneously.
- Open the REST API health monitor from Step 1.
- Enable Monitor SSL certificate.
- Set Alert when certificate expires in less than
30 days. - Click Save.
For self-hosted Nexus instances using Let's Encrypt:
# Check certificate expiry
openssl s_client -connect nexus.yourdomain.com:443 -servername nexus.yourdomain.com \
</dev/null 2>/dev/null | openssl x509 -noout -enddate
# notAfter=Sep 15 12:00:00 2026 GMT
For enterprise CA certificates:
# Check all certificates in your keystore
keytool -list -v -keystore /opt/sonatype/nexus/etc/ssl/keystore.jks \
-storepass YOUR_STORE_PASS | grep "Valid from"
The 30-day alert gives you time to coordinate certificate rotation with your PKI team before any outage.
Step 5: Heartbeat Monitoring for Nexus Scheduled Tasks
Nexus runs scheduled tasks for blob store compaction, database cleanup, component synchronization, and security vulnerability database updates. These tasks run silently in the background — if they stop running, Nexus gradually accumulates orphaned blobs, stale metadata, and outdated vulnerability data.
- In Vigilmon, click Add Monitor → Cron Heartbeat.
- Set Expected ping interval to
1440 minutes(24 hours) for daily cleanup tasks. - Copy the heartbeat URL:
https://vigilmon.online/heartbeat/YOUR_ID
Create a monitoring script that pings the heartbeat after verifying scheduled tasks completed:
#!/bin/bash
# /usr/local/bin/nexus-tasks-watchdog.sh
NEXUS_URL="https://nexus.yourdomain.com"
NEXUS_USER="admin"
NEXUS_PASS="YOUR_ADMIN_PASSWORD"
# Fetch last run time of cleanup task via REST API
LAST_RUN=$(curl -s -u "$NEXUS_USER:$NEXUS_PASS" \
"$NEXUS_URL/service/rest/v1/tasks" | \
jq -r '.items[] | select(.name == "Storage facet cleanup") | .lastRun')
echo "Last cleanup run: $LAST_RUN"
# Ping heartbeat to confirm script ran
curl -s https://vigilmon.online/heartbeat/YOUR_ID
Schedule via cron to run daily:
0 8 * * * /usr/local/bin/nexus-tasks-watchdog.sh
If a Nexus task hangs indefinitely (a known issue on large repositories with many orphaned blobs), the heartbeat stops, and Vigilmon alerts after 24 hours.
Step 6: Configure Alert Channels and Maintenance Windows
- In Vigilmon, go to Alert Channels and add Slack, PagerDuty, email, or a webhook.
- Set Consecutive failures before alert to
2on the primary health monitor — Nexus can take 60–90 seconds to respond during JVM garbage collection on large installations. - Add a maintenance window for Nexus upgrades:
# Before a Nexus upgrade
curl -X POST https://vigilmon.online/api/maintenance \
-H "Authorization: Bearer YOUR_VIGILMON_API_KEY" \
-H "Content-Type: application/json" \
-d '{"monitor_id": "YOUR_MONITOR_ID", "duration_minutes": 60}'
# Run the Nexus upgrade
systemctl stop nexus
# ... upgrade steps ...
systemctl start nexus
For Nexus Pro teams using High Availability clustering, monitor each node individually with separate Vigilmon monitors, then add a combined check for the load balancer endpoint. Node-level monitors let you distinguish a single-node failure from a full cluster outage.
Summary
| Monitor | Target | What It Catches |
|---|---|---|
| REST API health | /service/rest/v1/status | Nexus service down or degraded |
| Writable check | /service/rest/v1/status/writable | Blob store write failure |
| Web UI | / with keyword | UI down (Jetty/proxy issue) |
| Maven endpoint | /repository/maven-central/ | Maven repository failure |
| npm ping | /repository/npm-proxy/-/ping | npm registry failure |
| Docker v2 API | /v2/ | Docker registry failure |
| SSL certificate | Nexus domain | Certificate expiry (30-day warning) |
| Cron heartbeat | Heartbeat URL | Scheduled cleanup task failure |
Nexus is the shared infrastructure layer beneath every team's build system. When it degrades, the failure spreads silently — builds start failing, developers assume their code is broken, and it takes time to trace the root cause back to the artifact repository. With Vigilmon watching the health API, repository format endpoints, SSL certificate, and cleanup heartbeats, you catch Nexus problems in seconds rather than discovering them through a flood of build failure tickets.