tutorial

Monitoring Helpy with Vigilmon

Helpy is a self-hosted multi-channel helpdesk with email ticketing, community forum, and knowledge base — but it has no external uptime monitoring. Here's how to watch Helpy's web server, Sidekiq workers, Redis queue, PostgreSQL, email pipelines, and OAuth SSO with Vigilmon.

Helpy is an open-source multi-channel helpdesk platform built on Ruby on Rails. It handles email ticketing, a community forum, a knowledge base, and OAuth SSO — everything a support team needs in a self-hosted package. But Helpy ships with no external health monitoring: if the Rails app server goes down, Sidekiq stops processing background jobs, or PostgreSQL becomes unreachable, support tickets pile up and customers get no responses. Vigilmon gives you end-to-end monitoring for every Helpy service layer so a backend failure doesn't become a support team surprise.

What You'll Set Up

  • HTTP uptime monitor for the Helpy web server (port 3000)
  • Background job worker (Sidekiq) health monitoring
  • Redis queue broker connectivity check
  • PostgreSQL database availability monitor
  • Email inbound and outbound pipeline health
  • Knowledge base search and OAuth SSO endpoint monitoring
  • Webhook delivery service monitoring

Prerequisites

  • Helpy installed and running on port 3000 (or behind a reverse proxy on 80/443)
  • Sidekiq configured for background job processing
  • Redis running as the Sidekiq job broker
  • PostgreSQL as the primary database
  • A free Vigilmon account

Step 1: Monitor the Helpy Web Server

Helpy's Rails application serves the customer-facing portal, agent dashboard, forum, and knowledge base on port 3000 (or through nginx/Apache on port 80/443).

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter the Helpy URL: https://support.yourdomain.com
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

Helpy redirects unauthenticated users to the login page or the public knowledge base. Both return 200, so monitoring the root URL is an effective server health check.

For a more precise health check, add a Helpy health endpoint in your Rails app (config/routes.rb):

get '/health', to: proc {
  [200, { 'Content-Type' => 'application/json' }, ['{"status":"ok"}']]
}

Then monitor https://support.yourdomain.com/health with Expected response body contains set to "status":"ok". This endpoint bypasses authentication and returns quickly without a database query, making it ideal for high-frequency monitoring without adding database load.

Step 2: Monitor Sidekiq Background Job Workers

Helpy relies heavily on Sidekiq for background processing: sending email notifications, processing inbound emails, sending webhook callbacks, and running scheduled maintenance tasks. If Sidekiq goes down, all of these silently stop.

Sidekiq exposes a web UI (mountable in your Rails app) and a JSON stats endpoint. Add it to your routes:

# config/routes.rb
require 'sidekiq/web'
mount Sidekiq::Web => '/sidekiq'

Then add a Vigilmon monitor for the Sidekiq stats API:

https://support.yourdomain.com/sidekiq/stats
  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter the Sidekiq stats URL.
  3. Set Expected HTTP status to 200.
  4. Set Expected response body contains to "processes".
  5. Click Save.

The processes key lists active Sidekiq workers. If "processes":0, Sidekiq is registered in Redis but no worker processes are running. Set Expected response body does not contain to "processes":0 if your monitoring tool supports it — this alerts when all workers have disappeared.

Restrict the Sidekiq web UI to internal IPs or require authentication to avoid exposing job queue data publicly.

Step 3: Monitor Redis Queue Broker Connectivity

Sidekiq uses Redis as its job queue. If Redis becomes unreachable, Sidekiq workers stop pulling jobs and new jobs can't be enqueued — email delivery and webhook processing halt immediately.

Add a TCP monitor for Redis:

  1. Click Add Monitor → TCP Port.
  2. Enter Host: your-redis-host and Port: 6379.
  3. Set Check interval to 1 minute.
  4. Click Save.

For Redis with authentication or TLS, use an HTTP monitor against a small Redis health-check proxy, or check Redis availability via Helpy's own health endpoint (extend the Rails health check to test a Redis ping):

# config/routes.rb
get '/health', to: proc {
  redis_ok = begin
    Redis.new.ping == "PONG"
  rescue => e
    false
  end
  
  if redis_ok
    [200, { 'Content-Type' => 'application/json' }, ['{"status":"ok","redis":"ok"}']]
  else
    [503, { 'Content-Type' => 'application/json' }, ['{"status":"error","redis":"unreachable"}']]
  end
}

Now your /health endpoint returns 503 when Redis is down, and Vigilmon alerts on the status code change.

Step 4: Monitor PostgreSQL Database Connectivity

Helpy stores all tickets, users, forum posts, and knowledge base articles in PostgreSQL. If the database becomes unreachable, the Rails app returns 500 errors on every page load.

Add a TCP monitor for PostgreSQL:

  1. Click Add Monitor → TCP Port.
  2. Enter Host: your-postgres-host and Port: 5432.
  3. Set Check interval to 1 minute.
  4. Click Save.

Also extend the Rails health endpoint to include a database check:

get '/health', to: proc {
  db_ok = begin
    ActiveRecord::Base.connection.execute("SELECT 1")
    true
  rescue => e
    false
  end

  redis_ok = begin
    Redis.new.ping == "PONG"
  rescue
    false
  end

  status = (db_ok && redis_ok) ? "ok" : "error"
  code = status == "ok" ? 200 : 503

  body = { status: status, db: db_ok ? "ok" : "error", redis: redis_ok ? "ok" : "error" }.to_json
  [code, { 'Content-Type' => 'application/json' }, [body]]
}

The combined health endpoint now surfaces database and Redis failures in a single Vigilmon monitor, with the response body indicating which dependency failed.

Step 5: Monitor Email Inbound and Outbound Services

Email is Helpy's primary ticket creation channel. Inbound email (IMAP polling or SMTP relay) creates tickets; outbound SMTP delivers agent replies to customers. Both can fail silently.

Outbound email monitoring via heartbeat:

Set up a Sidekiq cron job (using sidekiq-cron or whenever) that sends a test email to a monitored address and pings Vigilmon on success:

# In a Sidekiq worker or scheduled task
class EmailHealthCheckWorker
  include Sidekiq::Worker

  def perform
    ActionMailer::Base.mail(
      to: 'healthcheck@yourdomain.com',
      subject: 'Helpy email health check',
      body: 'ok'
    ).deliver_now
    
    # Ping Vigilmon after successful delivery
    require 'net/http'
    Net::HTTP.get(URI('https://vigilmon.online/heartbeat/abc123'))
  rescue => e
    Rails.logger.error "Email health check failed: #{e.message}"
  end
end

Create a Vigilmon cron heartbeat monitor with an interval matching your test frequency (e.g. every 15 minutes). If the email worker fails or the SMTP server rejects the test message, the heartbeat goes silent and Vigilmon alerts.

Inbound email polling (IMAP):

Helpy polls an IMAP mailbox to create tickets from incoming emails. Monitor the IMAP polling indirectly: check the Sidekiq queue depth for the email-processing queue via the stats API. A growing queue that never drains indicates IMAP polling has failed.

Step 6: Monitor the Knowledge Base Search and Community Forum

Helpy's knowledge base search and forum rendering serve public-facing content. These can degrade independently of the main app if search indexing fails or the forum database queries become slow.

Knowledge base search:

https://support.yourdomain.com/en/docs
  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter the knowledge base URL.
  3. Set Expected HTTP status to 200.
  4. Set Expected response body contains to a string that appears in your knowledge base (e.g. a common article title or navigation element like "knowledge base" or "FAQ").
  5. Click Save.

Community forum:

https://support.yourdomain.com/community

Add an identical HTTP monitor for the forum URL. Set Expected response body contains to a string unique to the forum page — this catches Rails rendering errors that return 200 with an error page body instead of a proper 500.

Step 7: Monitor OAuth SSO Integration and Webhook Delivery

Helpy supports OAuth SSO for agent login. If the OAuth callback endpoint breaks, agents can't log in to the dashboard.

https://support.yourdomain.com/auth/google_oauth2
  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter the OAuth callback URL.
  3. Set Expected HTTP status to 302 (OAuth initiation redirects to the provider).
  4. Click Save.

A 500 on this endpoint means the OAuth middleware is broken, even if the rest of the app is functioning.

Webhook delivery monitoring:

For Vigilmon's heartbeat: create a Sidekiq cron job that fires a test webhook to Vigilmon's heartbeat URL every hour. This confirms both Sidekiq scheduling and outbound HTTP connectivity are working:

class WebhookHealthCheckWorker
  include Sidekiq::Worker

  def perform
    require 'net/http'
    Net::HTTP.get(URI('https://vigilmon.online/heartbeat/webhook123'))
  end
end

Step 8: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add Slack, email, or PagerDuty.
  2. For the web server and health endpoint monitors, set Consecutive failures before alert to 2 — Rails boot restarts cause brief downtime.
  3. For Sidekiq worker and email heartbeat monitors, set Consecutive failures before alert to 1 — a missed email delivery cycle is always an incident.
  4. For Redis and PostgreSQL TCP monitors, set Consecutive failures before alert to 2.
  5. Use Maintenance windows during Rails deployments:
# Open maintenance window before deployment
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "abc123", "duration_minutes": 5}'

# Deploy
bundle exec rails db:migrate
systemctl restart helpy

# Maintenance window expires automatically

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP web server | :3000 or :443 | Rails process crash, Puma/Unicorn failure | | Rails health endpoint | /health | Database or Redis connectivity failure | | Sidekiq web stats | /sidekiq/stats | Worker process stopped | | TCP Redis | :6379 | Job queue broker unavailable | | TCP PostgreSQL | :5432 | Database server unreachable | | Email heartbeat | Vigilmon URL | Outbound SMTP failure, inbound IMAP stopped | | Knowledge base | /en/docs | Search index failure, rendering error | | Community forum | /community | Forum rendering failure | | OAuth SSO | /auth/... | OAuth middleware broken | | Webhook heartbeat | Vigilmon URL | Sidekiq scheduling failure, outbound HTTP down |

Helpy's multi-channel architecture means a failure in any one layer can silently break a specific support workflow. A crashed Sidekiq worker doesn't break the forum but stops all email delivery; a failed IMAP poll stops ticket creation while agent replies still go out. With Vigilmon watching each layer independently, you'll know which channel is broken before your support queue tells you.

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