Uptime monitoring for Rudderstack customer data platform

Rudderstack is the event bus at the center of your analytics stack. Every user action — page views, purchases, signups, feature usage — flows through it on the way to your data warehouse, marketing tools, and product analytics platforms. When Rudderstack goes down, events are lost (or queued and replayed with delays), destinations receive stale data, and downstream reports become unreliable.

This tutorial covers production-grade uptime monitoring for Rudderstack using Vigilmon. We will walk through:

• Monitoring the /health endpoint
• Monitoring the event ingestion API (sourceTransformer)
• Checking destination sync status
• SSL certificate monitoring
• Heartbeat monitoring for scheduled transformations

Prerequisites

• Rudderstack open-source deployed (Docker Compose, Kubernetes, or bare metal)
• The data plane accessible on its public or private URL
• A free account at vigilmon.online

Part 1: Understand the Rudderstack health endpoint

Rudderstack exposes a /health endpoint on the data plane server (default port 8080). This is the canonical liveness check:

GET /health

A healthy data plane returns HTTP 200:

{
  "server": "1",
  "db": "1",
  "acceptingEvents": "TRUE",
  "routingEvents": "TRUE",
  "mode": "NORMAL",
  "goroutineCount": 248,
  "backendConfigMode": "API",
  "backendConfigLoop": "TRUE",
  "transformerLoop": "TRUE",
  "dgraph": ""
}

The key fields to check:

• "server": "1" — the data plane process is running
• "db": "1" — the Postgres backend (used for event queuing) is reachable
• "acceptingEvents": "TRUE" — the ingestion pipeline is active
• "mode": "NORMAL" — not in degraded or maintenance mode

If any of these fields change, Rudderstack is partially degraded even if the server is technically reachable.

Verify the health endpoint

curl http://localhost:8080/health

For cloud deployments:

curl https://events.example.com/health

Part 2: Configure the data plane URL for external access

The Rudderstack data plane must be publicly reachable for SDKs running in browsers and mobile apps to send events. If you have not already exposed it, use a reverse proxy:

# /etc/nginx/sites-available/rudderstack
server {
    listen 443 ssl;
    server_name events.example.com;

    ssl_certificate     /etc/letsencrypt/live/events.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/events.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

For Docker Compose deployments, the data plane is typically exposed on port 8080:

# docker-compose.yml (excerpt)
services:
  rudder-server:
    image: rudderlabs/rudder-server:latest
    ports:
      - "8080:8080"
    environment:
      RSERVER_BACKEND_CONFIG_CONFIG_FROM_FILE: "false"
      RSERVER_DB_HOST: db
      RSERVER_DB_PORT: "5432"
      RSERVER_DB_USER: rudder
      RSERVER_DB_NAME: jobsdb
      RSERVER_DB_PASSWORD: ${DB_PASSWORD}

Part 3: Set up HTTP monitoring in Vigilmon

Monitor the /health endpoint

1. Log in to vigilmon.online and click Add Monitor.
2. Choose HTTP(S) monitor.
3. Enter: https://events.example.com/health
4. Set interval to 1 minute.
5. Add a keyword check: must contain "acceptingEvents":"TRUE".
6. Add your alert channel.
7. Click Save.

The keyword check on acceptingEvents is more robust than checking for HTTP 200 alone. Rudderstack can return 200 from the health endpoint even when the database is overloaded and the event queue is paused. The acceptingEvents field will drop to FALSE in that case, triggering the keyword alert.

Monitor the event ingestion API

The Rudderstack data plane receives events at:

POST /v1/track
POST /v1/page
POST /v1/identify

You can add a secondary HTTP monitor using a test event to verify the ingestion pipeline is end-to-end functional. Create a Vigilmon HTTP monitor with a POST body:

1. Click Add Monitor, choose HTTP(S) monitor.
2. Enter: https://events.example.com/v1/track
3. Set method to POST.
4. Set body:

   {
     "userId": "vigilmon-healthcheck",
     "event": "Health Check Ping",
     "properties": { "source": "vigilmon" }
   }
   

5. Add header Content-Type: application/json.
6. Add header Authorization: Basic BASE64(WRITE_KEY:) (base64 of your write key followed by a colon).
7. Add keyword check: must contain "status":"OK".
8. Click Save.

Expected response from a healthy ingestion pipeline:

{ "status": "OK" }

Monitor the sourceTransformer (user transformations)

If you use Rudderstack's user transformations feature, the transformer service is a separate process. Check its health endpoint:

GET http://localhost:9090/health

Expose and monitor this endpoint with a Vigilmon HTTP monitor configured for https://transformer.example.com/health, with keyword check ok.

Part 4: Destination sync status monitoring

Rudderstack routes events to destinations (Segment, BigQuery, Amplitude, S3, etc.) asynchronously. Failed destinations can accumulate backlogged events without triggering any visible error.

Use the Rudderstack admin API

The data plane exposes an admin API (typically port 8648) for operational visibility:

# Check active and failed destinations
curl http://localhost:8648/v1/router/failedJobs

A healthy response returns an empty array []. A growing list of failed jobs indicates a destination sync is broken.

Add a Vigilmon monitor for this endpoint:

1. Click Add Monitor, choose HTTP(S) monitor.
2. Enter: https://admin.example.com/v1/router/failedJobs (expose carefully — this is an admin endpoint).
3. Set interval to 5 minutes.
4. Add a keyword check: must NOT contain a pattern that would indicate pending failures.
5. Alternatively, set up a webhook from your own monitoring wrapper that calls this endpoint and posts to Vigilmon.

Custom destination health wrapper

For production use, a lightweight wrapper script is more reliable than a raw keyword check on the jobs endpoint:

# destination_health_check.py
import requests
import sys

ADMIN_URL = "http://localhost:8648/v1/router/failedJobs"
THRESHOLD = 100  # Alert if more than 100 jobs are stuck

response = requests.get(ADMIN_URL, timeout=10)
failed_jobs = response.json()

if len(failed_jobs) > THRESHOLD:
    print(f"CRITICAL: {len(failed_jobs)} failed destination jobs", file=sys.stderr)
    sys.exit(1)

print(f"OK: {len(failed_jobs)} failed jobs (below threshold)")

Run this as a cron job and wire a heartbeat into it (see Part 6).

Part 5: SSL certificate monitoring

Rudderstack data plane URLs are embedded in client-side SDKs and mobile apps. An expired certificate breaks event ingestion for all clients simultaneously, and the failure is silent from the user's perspective — events are simply dropped or fail to send.

1. In Vigilmon, click Add Monitor.
2. Choose SSL monitor.
3. Enter each domain:
   • events.example.com (data plane / ingestion)
   • transformer.example.com (transformer service, if separately hosted)
4. Set alert threshold to 21 days before expiry.
5. Add your alert channel.

Part 6: Heartbeat monitoring for scheduled transformations

Rudderstack supports scheduled cron transformations — JavaScript functions that run on a schedule to process or enrich event data. These run silently and fail silently.

Set up a heartbeat monitor

1. In Vigilmon, click Add Monitor.
2. Choose Heartbeat monitor.
3. Name it Rudderstack Daily Transformation.
4. Set interval to 24 hours with a 2-hour grace period.
5. Copy the heartbeat URL: https://hb.vigilmon.online/ping/abc123
6. Click Save.

Wire the heartbeat into your transformation

Rudderstack user transformations are JavaScript functions. Add a ping at the end of long-running transformation logic:

// Rudderstack user transformation
export function transformEvent(event, metadata) {
  // Your transformation logic
  const enrichedEvent = enrichWithGeoData(event);

  // Ping Vigilmon after processing (for batch/scheduled transformations)
  fetch('https://hb.vigilmon.online/ping/abc123', { method: 'GET' })
    .catch(() => {}); // Non-blocking — don't let heartbeat failures break events

  return enrichedEvent;
}

For scheduled jobs outside Rudderstack that trigger transformation pipelines:

#!/bin/bash
# /opt/rudderstack/run-scheduled-transformation.sh

HEARTBEAT_URL="https://hb.vigilmon.online/ping/abc123"

# Trigger your transformation via Rudderstack API or external script
python3 /opt/rudderstack/run_transformation.py

if [ $? -eq 0 ]; then
    curl -fsS "$HEARTBEAT_URL"
else
    echo "Transformation failed — not pinging heartbeat" >&2
fi

Part 7: Webhook alerts and event pipeline incident response

Configure a Vigilmon webhook to receive DOWN/UP events and integrate with your data engineering on-call:

// rudderstack-alert-handler.ts
import express from 'express';

const app = express();
app.use(express.json());

app.post('/webhook/vigilmon', (req, res) => {
  const { monitor_name, status, url, checked_at } = req.body;

  if (status === 'down') {
    if (monitor_name.includes('health') || monitor_name.includes('ingestion')) {
      // Data plane down — events are being lost
      pageDataEngineeringOncall({
        message: `Rudderstack event ingestion DOWN since ${checked_at}`,
        severity: 'critical',
        runbook: 'https://wiki.example.com/runbooks/rudderstack-down',
      });
    } else if (monitor_name.includes('SSL')) {
      // Certificate expiring — less urgent but still critical
      createJiraTicket({
        project: 'INFRA',
        title: `Rudderstack SSL certificate expiring: ${url}`,
        priority: 'High',
      });
    }
  }

  res.sendStatus(204);
});

Vigilmon sends this payload on state transitions:

{
  "monitor_id": "mon_abc123",
  "monitor_name": "Rudderstack /health",
  "status": "down",
  "url": "https://events.example.com/health",
  "checked_at": "2026-07-12T08:01:00Z",
  "response_code": 503,
  "response_time_ms": 5000
}

Summary

Your Rudderstack deployment now has comprehensive monitoring across the full event pipeline:

1. /health endpoint with keyword check — confirms the data plane is accepting and routing events in NORMAL mode, polled every minute.
2. Ingestion API monitor — verifies the end-to-end event ingestion pipeline with a live test event.
3. Transformer service monitor — catches failures in the user transformation service that would silently drop or corrupt events.
4. SSL monitors — alerts 21 days before certificates expire on the ingestion and transformer domains.
5. Heartbeat monitors — detect silently failed scheduled transformations before stale data propagates to downstream destinations.

Vigilmon handles check scheduling, multi-region polling, alert routing, and uptime history. You get notified within 60 seconds of any failure in the event ingestion, transformation, or certificate layers — before events start dropping and before your analytics team notices stale dashboards.

Monitor your Rudderstack event pipeline free at vigilmon.online

#rudderstack #cdp #eventstreaming #monitoring #analytics #devops