How to Monitor OpenReplay with Vigilmon

OpenReplay is a self-hosted session replay and product analytics platform that lets you watch user sessions, track errors, and analyze funnels — without sending your users' behavioral data to a third-party SaaS. When you self-host OpenReplay, every session replay, every error track, and every heatmap depends on your infrastructure staying up.

This tutorial shows you how to set up comprehensive monitoring for OpenReplay using Vigilmon, covering the ingestion pipeline, replay viewer, and supporting services.

Why monitoring OpenReplay is critical

OpenReplay is a distributed system. It has an ingest API that collects session data in real time, a message queue (Apache Kafka) for buffering events, object storage (MinIO or S3) for storing recordings, and a frontend that lets your team replay sessions. Each layer can fail independently:

Ingest API downtime — your tracking script silently stops recording sessions; you lose user data with no indication until someone tries to replay and sees nothing
Storage backend failures — sessions are captured but recordings are never written to object storage; replays appear empty or fail to load
Replay viewer errors — the frontend returns a 500 or fails to load assets, blocking your team from analyzing sessions
Worker service stoppage — background workers that process raw events into replay-ready formats stop, causing sessions to appear stuck in "processing"
Backend service crashes — OpenReplay runs multiple microservices; the API gateway or individual services can crash without bringing down the entire system

External uptime monitoring gives you an objective signal that the ingestion pipeline and replay viewer are working end-to-end.

What you'll need

A running self-hosted OpenReplay instance (Docker Compose or Kubernetes)
A free Vigilmon account — no credit card required

Step 1: Understand OpenReplay's architecture and key endpoints

OpenReplay exposes these HTTP endpoints relevant to monitoring:

| Endpoint | Service | Purpose | |----------|---------|---------| | /health | API gateway | Overall system health probe | | /api/v1/health | Backend API | API service health | | / | Frontend (dashboard) | Web UI availability | | /ingest/v1/web/start | Ingest service | Session ingestion entry point | | /api/v1/assist/credentials | Assist service | Co-browsing service health |

Start with /health and the frontend root. Add the ingest endpoint check once you've verified the basic setup.

Step 2: Set up HTTP monitoring in Vigilmon

Monitor 1: System health check

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS

Set the URL to:

https://your-openreplay-domain.com/health

Check interval: 1 minute
Expected status code: 200
Save the monitor

This is your primary uptime signal. The /health endpoint aggregates the status of OpenReplay's core services.

Monitor 2: Dashboard (replay viewer) availability

Create a new HTTP / HTTPS monitor
URL:
```
https://your-openreplay-domain.com/
```
Expected status code: 200
(Optional) Response body contains: OpenReplay
Check interval: 3 minutes

This check confirms your team can actually open the replay dashboard. Frontend build failures, nginx misconfiguration, or static asset errors will all cause this to fail while the backend health check might still pass.

Monitor 3: Ingestion API availability

The ingestion endpoint is the most critical path for data collection. If it's down, you're losing session data in real time.

Create a new HTTP / HTTPS monitor
URL:
```
https://your-openreplay-domain.com/ingest/v1/web/not_started
```
(Send a probe to a non-session endpoint that still exercises the ingest service routing)
Expected status code: 200 or 404 — either proves the service is responding
Check interval: 1 minute

Alternatively, if your OpenReplay instance has a dedicated ingest domain (e.g., ingest.your-openreplay-domain.com), monitor that domain directly:

https://ingest.your-openreplay-domain.com/health

Monitor 4: API service

Create a new HTTP / HTTPS monitor

URL:

https://your-openreplay-domain.com/api/v1/health

Expected status code: 200
Check interval: 2 minutes

Step 3: Monitor the storage backend

OpenReplay stores session recordings in object storage (MinIO for self-hosted, or S3-compatible). Storage failures cause sessions to record but never become replayable.

If you're using MinIO (OpenReplay's default bundled storage), add a TCP check:

Go to Monitors → New Monitor
Choose TCP Port
Enter:
- Host: your-openreplay-domain.com (or your MinIO host)
- Port: 9000 (MinIO default API port)
Check interval: 2 minutes

If you're using an external S3-compatible endpoint, monitor the storage access endpoint:

Create an HTTP / HTTPS monitor
URL: your MinIO or S3-compatible endpoint's health URL
Expected status code: 200

Step 4: Set up TCP monitoring for core services

TCP checks verify that OpenReplay's service ports are reachable at the network level.

| Service | Default Port | What to monitor | |---------|-------------|-----------------| | HTTPS proxy | 443 | Nginx / reverse proxy | | HTTP redirect | 80 | HTTP → HTTPS redirect | | MinIO API | 9000 | Object storage API port |

For each port you want to monitor:

Monitors → New Monitor → TCP Port
Enter hostname and port
Set interval to 1 minute

Step 5: Configure your deployment for health check compatibility

If running OpenReplay via Docker Compose, ensure your docker-compose configuration exposes the health endpoint:

# Excerpt from docker-compose.yml (OpenReplay community edition)
services:
  nginx:
    image: openreplay/nginx:latest
    ports:
      - "80:80"
      - "443:443"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

  api:
    image: openreplay/api:latest
    environment:
      pg_host: postgres
      pg_port: 5432
      MINIO_HOST: minio
      MINIO_PORT: 9000
    depends_on:
      - postgres
      - minio
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/api/v1/health"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

  minio:
    image: minio/minio:latest
    command: server /data --console-address ":9001"
    volumes:
      - minio_data:/data
    environment:
      MINIO_ROOT_USER: ${MINIO_ACCESS_KEY}
      MINIO_ROOT_PASSWORD: ${MINIO_SECRET_KEY}
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 5s
      retries: 3
    restart: unless-stopped

volumes:
  minio_data:

Adding health checks to Docker services enables container-level auto-restart. Vigilmon then provides the alerting layer on top — notifying you when a restart occurs and measuring how long the outage lasted.

Step 6: Configure alert channels

In Vigilmon, go to Alert Channels → Add Channel
Set up alerts appropriate for your team:
- Slack — primary alert destination for the engineering team
- Email — for product managers who depend on session replays for UX research
- PagerDuty — if missing session data has immediate business consequences

For OpenReplay, we recommend tiered alerting:

Critical (immediate pager): /health endpoint down → sessions are not being recorded
High (Slack alert): Ingest API down → same consequence, different failure mode
Medium (email, business hours): Dashboard unavailable → team can't review sessions

Step 7: Set up a status page

Create a status page so engineers and product managers can see OpenReplay's health at a glance:

Go to Status Pages → New Status Page
Add monitors: "Session Ingestion", "Replay Dashboard", "API Service", "Object Storage"
Publish the page
Share the URL in your team wiki or Slack channel topic

Complete monitor setup summary

| Monitor | Type | Target | Interval | Catches | |---------|------|--------|----------|---------| | System health | HTTP | /health | 1 min | Core service failures | | API service | HTTP | /api/v1/health | 2 min | API backend crashes | | Dashboard | HTTP | / | 3 min | Frontend build / asset failures | | Ingest API | HTTP | /ingest/v1/web/... | 1 min | Session recording data loss | | HTTPS port | TCP | :443 | 1 min | Reverse proxy failures | | MinIO port | TCP | :9000 | 2 min | Object storage network issue |

Conclusion

OpenReplay gives you the session replay power of FullStory or LogRocket with complete data ownership. But self-hosting means you're on the hook for availability — and the consequences of ingest downtime are uniquely invisible (you don't lose page views, you lose behavioral data you didn't know you were missing).

With Vigilmon's continuous monitoring, you get instant visibility into every component of the OpenReplay stack. Set up monitors once, configure your alert channels, and rest easy knowing you'll never silently lose session data again.

Start monitoring for free at vigilmon.online.