Returns JSON: {"status":"ok","version":"0.x.y","isAuthenticated":false}

title: "Monitoring Lightdash with Vigilmon: API Health, Dashboard Availability, Background Jobs & SSL Certificate Alerts" published: false description: How to monitor Lightdash open-source BI platform with Vigilmon — API health checks, dashboard UI availability, scheduler job monitoring, and SSL certificate alerts. tags: lightdash, business-intelligence, analytics, monitoring, postgresql, dbt cover_image:

Lightdash is the open-source business intelligence platform that sits on top of your dbt project — giving analysts and product teams self-serve access to metrics defined in code. When Lightdash's API server goes down, nobody can open dashboards, run queries, or refresh charts. When the scheduler fails, scheduled reports stop delivering and dashboard cache refreshes silently stop running. When the background worker disconnects from the database, queries queue indefinitely without error messages that reach end users. Vigilmon gives you external visibility into Lightdash's availability: the API health endpoint, web UI, scheduler health, and SSL certificate expiry.

What You'll Build

• A monitor on Lightdash's health API to detect service-level failures
• A web UI availability check to confirm the dashboard portal is accessible
• An HTTP monitor on the scheduler health endpoint to detect background job failures
• SSL certificate monitoring for your Lightdash domain
• An alerting setup that distinguishes API failures from UI rendering issues

Prerequisites

• A running Lightdash instance (Docker Compose, Kubernetes, or cloud deployment)
• HTTPS configured and accessible externally (e.g., https://lightdash.example.com)
• A free account at vigilmon.online

Step 1: Understand Lightdash's Health Endpoints

Lightdash exposes health and status endpoints through its API server. The primary health endpoint is:

curl https://lightdash.example.com/api/v1/health

A healthy response returns HTTP 200 with a JSON body containing "status":"ok". If the API server process is crashed, you receive a connection refused error. If the database connection pool is exhausted, the endpoint may hang or return a 503.

Lightdash also exposes a scheduler health check (when using the built-in scheduler):

curl https://lightdash.example.com/api/v1/schedulerStatus
# Returns scheduler queue depth and worker status

Step 2: Create a Vigilmon HTTP Monitor for the API Health Endpoint

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://lightdash.example.com/api/v1/health.
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: "status":"ok" (present in every healthy response body).
7. Click Save.

This monitor catches:

• Lightdash API server process crashes or restarts
• PostgreSQL connection failures that prevent the health endpoint from responding
• Memory pressure causing the Node.js process to be killed by the OS
• Container restarts after unhealthy health checks in Docker or Kubernetes
• Configuration errors after Lightdash version upgrades (missing env vars, schema mismatches)
• Redis disconnects that cause the API to hang on queue operations

Alert sensitivity: Set to trigger after 1 consecutive failure. When the Lightdash API is down, all dashboard access and scheduled reports fail immediately.

Step 3: Monitor the Lightdash Web UI

The API health endpoint checks the backend process. A separate monitor on the root URL confirms that the frontend is being served correctly — catching reverse proxy failures, CDN misconfigurations, and static asset serving errors that the backend health check doesn't detect.

curl https://lightdash.example.com
# Returns HTML with Lightdash in the page content

1. Add Monitor → HTTP.
2. URL: https://lightdash.example.com.
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: Lightdash (present in the page title of a healthy frontend).
7. Click Save.

This catches failures specific to the frontend path:

• Nginx or reverse proxy misconfiguration that blocks static file serving
• Frontend container restarting independently of the API container
• CDN cache poisoning that serves error pages to end users
• Memory limit OOM kills of the frontend process in resource-constrained deployments

Step 4: Monitor the Background Scheduler

Lightdash's scheduler delivers scheduled dashboard deliveries (email, Slack), runs chart cache refreshes, and handles async query jobs. A scheduler failure is silent to end users until they notice their scheduled reports stop arriving.

curl https://lightdash.example.com/api/v1/schedulerStatus

1. Add Monitor → HTTP.
2. URL: https://lightdash.example.com/api/v1/schedulerStatus.
3. Check interval: 300 seconds (5 minutes).
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Click Save.

This catches:

• Scheduler worker process crashes (separate from the API process in containerized deployments)
• Redis connectivity failures that prevent the job queue from being consumed
• Database write permission errors that block scheduled delivery logging
• Timezone configuration issues that cause scheduled jobs to never fire

Step 5: Add SSL Certificate Monitoring

Analytics tools like Lightdash are business-critical — certificate expiry that breaks HTTPS access means analysts can't open dashboards, leading to support tickets and business disruption.

1. Add Monitor → SSL Certificate.
2. Domain: lightdash.example.com.
3. Alert threshold: 21 days before expiry.
4. Click Save.

Certificate issues are common on self-hosted Lightdash deployments when:

• Let's Encrypt auto-renewal via certbot or cert-manager fails silently
• Manual certificate upload to the reverse proxy is missed during renewal
• Wildcard certificate renewals require DNS challenges that aren't automated

Step 6: Configure Alert Channels

Lightdash serves business users (analysts, product managers) who expect dashboards to be available during business hours. Configure alerts accordingly:

1. Go to Alerts → Channels → Add Channel.
2. Slack: route API down and UI down alerts to an #analytics-ops or #data-platform channel.
3. Email: notify the data platform team lead for any outage lasting more than 5 minutes.
4. PagerDuty: optional for most internal Lightdash deployments.

Recommended notification rules:

• API health down → immediate Slack alert (1 failure threshold)
• UI down → immediate Slack alert
• Scheduler down → Slack alert (3-failure threshold — allow for transient restarts)
• SSL certificate < 21 days → Slack alert (low urgency)

Step 7: Set Up a Status Page for Analytics Consumers

Lightdash's user base — analysts and business stakeholders — benefits from a status page:

1. Go to Status Pages → New Status Page.
2. Name: "Analytics Platform".
3. Add monitors: API health, web UI, scheduler.
4. Publish and share the URL with your analytics team Slack channel.

During Lightdash upgrades, enable a Maintenance Window in Vigilmon before the deployment so the status page shows "Scheduled Maintenance" instead of "Down" and alerts are suppressed.

Step 8: Verify Your Setup

With Lightdash running, confirm all monitors show Up in the Vigilmon dashboard:

# Confirm the health endpoint returns status ok
curl -s https://lightdash.example.com/api/v1/health

# Confirm the UI serves the Lightdash page
curl -s https://lightdash.example.com | grep -i "lightdash"

What You've Built

Your Vigilmon setup now covers four independent failure modes for Lightdash:

| Monitor | Failure Mode Caught | |---------|-------------------| | HTTP /api/v1/health | API server crashes, database connection failures | | HTTP root URL | Frontend serving failures, reverse proxy issues | | HTTP /api/v1/schedulerStatus | Background job failures, Redis disconnects | | SSL Certificate | Certificate expiry blocking HTTPS dashboard access |

Each monitor fires independently, so you can distinguish "API server is down" from "scheduler has stopped" from "SSL is expired" without grepping through logs.