How to Monitor OpenProject with Vigilmon

OpenProject is a powerful open-source project management platform used by thousands of engineering and operations teams. When your OpenProject instance goes down, your entire team loses access to project plans, roadmaps, and issue trackers. Vigilmon monitors your OpenProject deployment from multiple regions and alerts you the instant something breaks — before your team starts filing tickets.

What You'll Set Up

• HTTP monitor for the OpenProject health endpoint (/health_checks/all)
• Web UI availability check on the main application URL
• Background job (worker) heartbeat monitor
• SSL certificate expiry alert

Prerequisites

• A running OpenProject instance (self-hosted via Docker, DEB/RPM packages, or a managed cloud)
• A free Vigilmon account

Why Monitor OpenProject

OpenProject has several runtime dependencies that can fail independently: the Ruby on Rails application server, a PostgreSQL database, Sidekiq background workers, and a Memcached or Redis cache. A failure in any layer can produce partial degradation — the UI may load while scheduled notifications stop, or the database may become unreachable while the Nginx frontend still returns cached responses. External monitoring from Vigilmon catches these failures from the outside in, the same way your users experience them.

Step 1: Monitor the Health Endpoint

OpenProject exposes a built-in health check at /health_checks/all that verifies internal subsystems including the database, cache, and job queue. This is your primary monitoring target.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your health URL: https://openproject.yourdomain.com/health_checks/all
4. Set Check interval to 1 minute.
5. Set Expected status code to 200.
6. In Expected body contains, enter "healthy" — the endpoint returns JSON with a "healthy": true field when all subsystems pass.
7. Click Save.

If the database or job queue degrades, the endpoint returns a non-200 status and Vigilmon fires an alert.

Step 2: Monitor Web UI Availability

The health endpoint tests internal services, but your users interact with the web UI. Add a second monitor for the main application URL:

1. Click Add Monitor again.
2. Set Type to HTTP / HTTPS.
3. Enter: https://openproject.yourdomain.com
4. Set Expected status code to 200.
5. In Expected body contains, enter OpenProject — this verifies the page renders correctly, not just that the server responds.
6. Set Response time threshold: warn at 1500ms, critical at 4000ms — OpenProject's initial page load is heavier than a static site.
7. Save and assign to your alert channel.

Step 3: Monitor Background Jobs (Sidekiq Worker)

OpenProject uses Sidekiq workers to process email notifications, project exports, and scheduled tasks. If the worker stops, jobs silently pile up — users won't receive email alerts and exports will hang indefinitely.

Use Vigilmon's heartbeat monitor to confirm the worker is alive:

1. In Vigilmon, click Add Monitor → Heartbeat.
2. Name it OpenProject Sidekiq Worker.
3. Set the Expected interval to 5 minutes and Grace period to 2 minutes.
4. Copy the generated heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Now add a cron job on your OpenProject server that pings this URL while the Sidekiq process is running. Using Docker Compose, add a healthcheck or sidecar script; for bare-metal installs:

# Add to crontab with: crontab -e
*/5 * * * * pgrep -x sidekiq > /dev/null && curl -fsS --max-time 10 https://vigilmon.online/heartbeat/abc123

This pings Vigilmon every 5 minutes only if the Sidekiq process is alive. If the worker crashes or the cron stops running, Vigilmon alerts you after the grace period expires.

Step 4: SSL Certificate Monitoring

An expired SSL certificate locks all users out of OpenProject instantly. Vigilmon monitors certificate expiry automatically — no separate setup needed.

For monitors you created in Steps 1 and 2:

1. Open each monitor's settings.
2. Enable SSL certificate alert.
3. Set the Warn threshold to 21 days before expiry and Critical to 7 days.

You'll receive an alert well before the certificate expires, giving your team time to renew via Let's Encrypt or your CA.

Step 5: Configure Alert Channels

Route all four monitors to your preferred notification channels:

1. In Vigilmon, go to Alert Channels → Add Channel.
2. Choose Email, Slack, PagerDuty, or Webhook.
3. For Slack, paste an incoming webhook URL and test it.
4. Attach the channel to all OpenProject monitors under each monitor's Alert Channels tab.

For on-call teams, PagerDuty integration ensures the right engineer is paged at any hour.

Step 6: Verify the Setup

Before relying on these monitors in production, run a quick test:

1. Temporarily change one monitor's Expected body contains to a string that won't match (e.g. DOESNOTEXIST) and confirm an alert fires within 2 minutes.
2. Restore the correct value and confirm a recovery notification arrives.
3. Check the Response time history chart on the Vigilmon dashboard — a spike pattern here often predicts database or worker saturation before it causes a full outage.

What to Monitor Next

• API availability: OpenProject exposes a REST API at /api/v3. Add a monitor for https://openproject.yourdomain.com/api/v3 to confirm API clients and integrations stay connected.
• Disk space: Full disks crash both PostgreSQL and attachment uploads. Combine host-level metrics with Vigilmon's external checks for complete coverage.
• Status page: Enable Vigilmon's public status page so your team can self-check service status during an incident instead of flooding Slack.

Your OpenProject instance is now monitored end-to-end: subsystem health, web UI rendering, background worker liveness, and SSL expiry — all from a single Vigilmon dashboard.