Monitoring Self-Hosted ReportPortal with Vigilmon

ReportPortal aggregates test results from your CI pipelines, applies ML-based failure analysis, and presents historical quality trends in a single dashboard. Self-hosting keeps your test data on your own infrastructure — but it also puts you in charge of keeping ReportPortal's eight-plus microservices running reliably. When the analytics pipeline silently stalls or the storage backend becomes unreachable, test results stop arriving without any obvious error. Vigilmon monitors each critical service endpoint so you catch ReportPortal degradations before they corrupt your quality data.

What You'll Set Up

• HTTP health monitor for the ReportPortal API gateway on port 8080
• Service health checks for the analyzer, job executor, and UI
• Storage backend (MinIO) port monitoring
• PostgreSQL database availability check
• Alerting configuration

Prerequisites

• ReportPortal 5.x or later installed via Docker Compose
• ReportPortal accessible on port 8080 (default gateway port)
• A free Vigilmon account

Step 1: Monitor the ReportPortal API Gateway

The API gateway is the entry point for all ReportPortal traffic — both the web UI and reporting clients send requests through it. Monitor the gateway health endpoint:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the URL: http://your-reportportal-host:8080/api/v1/health
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Under Keyword match, enter "status":"UP" to validate the response payload.
7. Click Save.

The health endpoint aggregates status from connected downstream services. A partial outage — such as the analyzer service being down — surfaces here as a degraded response before individual service failures become visible to users.

Step 2: Monitor the ReportPortal Web UI

The web UI runs as its own service and can fail independently of the API gateway.

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://your-reportportal-host:8080/ui/
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Under Keyword match, enter ReportPortal to confirm the correct application is being served (not a default nginx page).
6. Click Save.

If the UI container crashes but the API gateway is still running, the gateway returns errors for UI requests while API-based reporting continues — a confusing split state that separate monitors make obvious.

Step 3: Monitor the Analyzer Service

ReportPortal's ML-based analyzer (the analyzer or auto-analyzer service) processes test failures to identify patterns. If this service goes down, new failures won't be categorized and historical analysis halts — silently.

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://your-reportportal-host:8081 (default analyzer port; adjust if running in a Docker network with a different external mapping).
3. Set Check interval to 3 minutes.
4. Set Expected HTTP status to 200.
5. Click Save.

If you're using Docker Compose with the default ReportPortal configuration, you can check the analyzer from within the Docker network. For external monitoring, ensure the analyzer port is exposed or use the gateway's health aggregation response — a down analyzer shows as degraded in the /api/v1/health payload.

Step 4: Monitor the Job Executor

The job executor handles scheduled tasks: log cleanup, launch retention, and notification delivery. A stalled job executor stops old test results from being purged, which causes storage to fill up silently over time.

Add a heartbeat monitor for the job executor:

1. Click Add Monitor → Cron Heartbeat.
2. Set the expected ping interval to 24 hours (executor runs daily cleanup jobs).
3. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Add a ping to your job executor container's startup script or to a scheduled task on your server:

#!/bin/bash
# /usr/local/bin/rp-executor-check.sh

# Check if the executor container is running
if docker inspect reportportal-jobs --format='{{.State.Status}}' 2>/dev/null | grep -q "running"; then
  curl -s --max-time 10 https://vigilmon.online/heartbeat/abc123
fi

Schedule it daily:

0 6 * * * /usr/local/bin/rp-executor-check.sh

Step 5: Monitor the Storage Backend (MinIO)

ReportPortal stores test attachments, screenshots, and logs in MinIO object storage. A MinIO failure causes test launches to fail to save attachments, but the test result records themselves may still appear — leading to incomplete data with no obvious error.

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://your-reportportal-host:9000/minio/health/live
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Click Save.

MinIO exposes a dedicated health endpoint at /minio/health/live. A 200 confirms MinIO is healthy; a 503 means it's in a degraded or unavailable state.

Also add a TCP port monitor as a secondary check:

1. Click Add Monitor → TCP Port.
2. Host: your-reportportal-host
3. Port: 9000
4. Set Check interval to 2 minutes.
5. Click Save.

Step 6: Monitor the PostgreSQL Database

ReportPortal stores all launch metadata, test items, and user data in PostgreSQL. Database connectivity failures cause the API to return errors on every test report submission.

1. Click Add Monitor → TCP Port.
2. Host: your-reportportal-host
3. Port: 5432 (default PostgreSQL port)
4. Set Check interval to 2 minutes.
5. Click Save.

A TCP monitor verifies PostgreSQL accepts connections. Pair it with the API gateway health monitor — if the gateway is degraded and the PostgreSQL TCP check is failing, the database is the most likely root cause.

Step 7: Configure SSL and Alerting

SSL certificate monitoring

If you've placed ReportPortal behind an nginx or Traefik reverse proxy with TLS:

1. Open the gateway monitor created in Step 1.
2. Update the URL to https://reportportal.yourdomain.com.
3. Enable Monitor SSL certificate.
4. Set Alert when certificate expires in less than 21 days.
5. Click Save.

Alert channels and noise reduction

1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
2. Assign the channel to each ReportPortal monitor.
3. Set Consecutive failures before alert to 2 on the API gateway monitor — ReportPortal services can take 30–60 seconds to restart.

Maintenance windows

ReportPortal database migrations during upgrades can take several minutes. Use the Vigilmon API to suppress alerts:

curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "monitor_id": "reportportal-gateway-id",
    "duration_minutes": 20
  }'

docker compose pull && docker compose up -d

Summary

| Monitor | Target | What It Catches | |---|---|---| | API gateway health | :8080/api/v1/health | Gateway or downstream service down | | Web UI | :8080/ui/ | UI container crash | | Analyzer service | :8081 | ML analysis pipeline stopped | | Job executor heartbeat | Daily cron ping | Cleanup/notification jobs stalled | | MinIO HTTP health | :9000/minio/health/live | Object storage degraded | | PostgreSQL TCP | :5432 | Database connectivity loss |

ReportPortal's multi-service architecture means a single failing container can degrade quality analytics in ways that aren't immediately visible. With Vigilmon watching the gateway, analyzer, storage, and database independently, you'll detect the specific component that failed — not just that "ReportPortal seems slow" — so your team can act quickly and keep test data flowing.