tutorial

Monitoring PipeRider with Vigilmon: Data Pipeline Testing Platform Health, Report Availability & Webhook Delivery

How to monitor PipeRider open-source data pipeline testing and profiling infrastructure with Vigilmon — report server uptime, API availability, webhook delivery health, and SSL certificate validity.

PipeRider is the open-source data pipeline testing and profiling tool that generates detailed HTML reports on data schema, row counts, distribution statistics, and assertion results — giving data engineers a repeatable way to validate data quality before and after pipeline changes. When the PipeRider report server goes down, data teams lose access to the profiling reports and test run comparisons they need to audit pipeline changes. When the Cloud API is unavailable, automated CI/CD integrations that push PipeRider reports to shared workspaces fail silently, and comparison summaries stop posting to pull requests. When webhook delivery fails, integrations with GitHub, Slack, and PagerDuty stop receiving test failure notifications, leaving data quality regressions unacknowledged until they reach downstream consumers. Vigilmon gives you external visibility into PipeRider's infrastructure: the report server, cloud API, and webhook endpoints, so you know the moment the pipeline testing platform itself needs attention.

What You'll Build

  • An HTTP monitor on the PipeRider report server or cloud dashboard to detect availability failures
  • A health-check monitor on the PipeRider Cloud API to catch backend degradation
  • A monitor on your webhook receiver to verify PipeRider alert delivery is flowing
  • A monitor on the PipeRider Cloud comparison endpoint to catch report upload failures
  • An SSL certificate monitor for your PipeRider domain
  • Alerting that distinguishes report server outages from cloud API failures

Prerequisites

  • A PipeRider deployment (open-source CLI with self-hosted report server, or PipeRider Cloud)
  • The PipeRider report server or cloud dashboard exposed via HTTPS
  • A webhook receiver endpoint configured to accept PipeRider test failure alerts
  • A free account at vigilmon.online

Step 1: Understand PipeRider's Service Architecture

PipeRider can be operated in two modes, each with a different monitoring surface:

| Component | Default port | Role | |---|---|---| | PipeRider report server (self-hosted) | 8888 or 443 (HTTPS) | Serves static HTML profiling reports and assertion run history | | PipeRider Cloud dashboard | 443 (HTTPS) | Hosted workspace for sharing and comparing reports across teams | | PipeRider Cloud API | 443 (HTTPS) | Receives report uploads from the piperider CLI; serves comparison data | | Alert dispatcher | Outbound | Delivers test failure notifications to GitHub, Slack, and custom webhooks |

External monitoring focuses on the report server (or cloud dashboard) and the cloud API endpoints — these surface the availability of the entire PipeRider deployment and are the interfaces your data engineers and CI/CD pipelines interact with directly.

Step 2: Monitor the PipeRider Report Server or Cloud Dashboard

The PipeRider report server (or cloud dashboard) is the primary interface for reviewing profiling statistics, viewing assertion failures, and comparing report runs to identify data drift between pipeline executions:

# Self-hosted report server
curl -I https://piperider.your-domain.com

# PipeRider Cloud
curl -I https://cloud.piperider.io
# Returns HTTP 200 with HTML when the frontend is healthy
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://piperider.your-domain.com (self-hosted) or https://cloud.piperider.io (cloud).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: PipeRider (appears in the page title and HTML content).
  7. Click Save.

This monitor catches:

  • PipeRider report server process crashes or failed report regeneration
  • Static file server or Nginx misconfigurations blocking report access
  • Failed PipeRider upgrades that leave the report server returning 5xx errors
  • DNS resolution failures for the PipeRider domain

Alert sensitivity: Set to trigger after 1 consecutive failure. When the PipeRider report server is unavailable, data engineers cannot review the profiling baseline for a pipeline change or access assertion failure details during a data quality incident.

Step 3: Monitor the PipeRider Cloud API

For teams using PipeRider Cloud, the cloud API receives report uploads from the piperider CLI after each pipeline run and powers the shared workspace comparison dashboard. When the API is degraded, piperider cloud upload commands fail and report comparisons between runs stop appearing in the shared workspace:

curl https://api.piperider.io/health
# Returns: {"status": "ok"} when the API is healthy
  1. Add Monitor → HTTP.
  2. URL: https://api.piperider.io/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok (present in healthy API responses).
  7. Label: PipeRider Cloud API health.
  8. Click Save.

Why monitor the cloud API separately from the dashboard? The cloud dashboard may display the last successfully uploaded report even when the API is down. A failing API means piperider CLI invocations at the end of your pipeline runs cannot upload results to the shared workspace, and automated PR comparison comments stop being posted to your dbt or SQL pull requests.

Step 4: Monitor Your Webhook Receiver

PipeRider delivers data assertion failure alerts and run completion notifications to your on-call tools (GitHub, Slack, PagerDuty, custom webhooks) via outbound HTTP calls. If your webhook receiver becomes unavailable or returns errors, notification delivery fails silently — pull requests no longer receive automated test failure summaries and on-call engineers stop receiving data quality alerts:

curl https://your-webhook-receiver.example.com/health
# Returns: {"status": "ok"} when the receiver is up
  1. Add Monitor → HTTP.
  2. URL: https://your-webhook-receiver.example.com/health.
  3. Check interval: 2 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: PipeRider webhook receiver.
  8. Click Save.

For GitHub status verification, monitor https://www.githubstatus.com/api/v2/status.json to confirm the GitHub API is reachable for PR comment delivery. For Slack incoming webhooks, verify https://slack.com/api/api.test.

Step 5: Monitor the PipeRider Cloud Comparison Endpoint

PipeRider Cloud's comparison endpoint powers the run-over-run diff feature that highlights changes in row counts, schema, and distribution statistics between pipeline executions. When this endpoint is degraded, the comparison dashboard fails to load and CI/CD integrations cannot generate comparison summaries for pull request comments:

curl https://api.piperider.io/v1/compare/status
# Returns comparison engine status and last successful comparison timestamp
  1. Add Monitor → HTTP.
  2. URL: https://api.piperider.io/v1/compare/status.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: status (present in the response JSON).
  7. Label: PipeRider Cloud comparison.
  8. Click Save.

Comparison endpoint failures mean the piperider compare command and automated CI comparison summaries return errors, forcing engineers to manually inspect individual JSON report files rather than using the visual diff interface.

Step 6: Monitor SSL Certificates

PipeRider's report server and cloud API are accessed over HTTPS by both data engineers reviewing reports and the piperider CLI that uploads results at the end of automated pipeline runs in CI/CD. An expired certificate breaks both browser access to reports and automated CLI uploads:

# Self-hosted report server
openssl s_client -connect piperider.your-domain.com:443 2>/dev/null | openssl x509 -noout -dates

# PipeRider Cloud API
openssl s_client -connect api.piperider.io:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: piperider.your-domain.com or api.piperider.io.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

CI/CD pipeline impact: The piperider CLI runs as a CI step and calls the cloud API to upload profiling results. When the certificate expires, these uploads fail with TLS errors. CI pipelines that treat PipeRider as a non-blocking step may continue and merge the PR without the profiling report, leaving the workspace with a gap in run history that breaks future comparison baselines.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Report server / Cloud dashboard | Non-200 or PipeRider missing | Check report server process or PipeRider Cloud status | | Cloud API health | Non-200 or ok missing | API down; piperider uploads failing; check PipeRider Cloud status page | | Webhook receiver | Non-200 or ok missing | PR comments and on-call alerts not delivering; verify receiver deployment | | Cloud comparison | Non-200 or status missing | Run comparisons failing; check PipeRider Cloud status; inspect API logs | | SSL certificate | < 30 days to expiry | Renew certificate; verify piperider CLI reconnects after renewal |

Alert after: 1 consecutive failure for the report server and API health monitors. 2 consecutive failures for cloud comparison and webhook receiver monitors to reduce noise from transient network issues during report upload bursts in CI.

Common PipeRider Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Report server process crash | Report server monitor fires; engineers cannot review profiling baselines | | PipeRider Cloud API degradation | Cloud API monitor fires; piperider uploads fail; workspace shows stale runs | | Webhook receiver crash | Webhook receiver monitor fires; PR summaries and on-call alerts stop posting | | Comparison endpoint failure | Comparison monitor fires; piperider compare returns errors; CI summaries absent | | TLS certificate expired | SSL monitor alerts at 30-day threshold; piperider CLI and browsers fail | | DNS misconfiguration | All monitors fire simultaneously | | Cloud API auth token rotation breaks CLI | Cloud API monitor may fire; uploads fail with 401 authentication errors | | PipeRider upgrade breaks report format | Report server monitor may fire if server fails to parse new report schema |

Monitoring Pipeline Test Results Themselves (Beyond Infrastructure)

Vigilmon monitors PipeRider's infrastructure endpoints — the report server, cloud API, comparison engine, and webhook receiver. The health of individual data assertions and profiling test results is a separate concern that requires configuration within PipeRider itself:

  • PipeRider's built-in alerting: Configure notification channels within PipeRider (Slack, GitHub, custom webhooks) to route assertion failures to on-call teams — this is distinct from monitoring PipeRider's own availability.
  • Assertion coverage: Audit which data sources and pipeline stages have PipeRider assertions configured to ensure new tables and models are covered automatically when they are added.
  • Baseline management: PipeRider's comparison baselines are built from historical run history. A gap in report uploads (caused by a cloud API failure) can distort future comparisons — review the comparison dashboard after any API outage to verify baselines are still accurate.

Vigilmon catches infrastructure-level failures — when PipeRider itself is down. Assertion failures and profiling regressions within a healthy PipeRider deployment require PipeRider's own test configuration and notification rules.

PipeRider is the layer that makes your data pipeline changes auditable — when it goes down, profiling reports stop generating, run-over-run comparisons break in CI, and data engineers lose the statistical baseline they rely on to catch volume drops and schema drift before they reach production. Vigilmon gives you external visibility into PipeRider's availability that doesn't depend on PipeRider self-reporting: report server uptime, cloud API health, comparison engine status, and SSL certificate validity, so you know the moment the pipeline testing platform itself needs attention and can restore data quality profiling before the next pipeline change ships without a baseline comparison.

Start monitoring PipeRider in under 5 minutes — register free at vigilmon.online.

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