Databand, now part of IBM Observability, is the data pipeline observability and incident management platform that gives data engineering teams the visibility to detect, triage, and resolve data pipeline failures before they impact downstream consumers — tracking pipeline run history, data quality metrics, execution anomalies, and SLA violations across Airflow, Spark, dbt, and Kafka pipelines so teams can respond to data incidents with the same speed and rigor that DevOps teams apply to application incidents. When the Databand platform becomes unavailable, the pipeline observability coverage that surfaces failed runs, late deliveries, and data quality violations goes dark: SLA breach alerts stop firing, anomaly detection stops comparing run metrics against historical baselines, and the incident management workflows that coordinate remediation between data engineers and analytics consumers lose their alerting layer. When the Databand API degrades, Airflow operators that report pipeline run metadata to Databand and CI/CD pipelines that check data quality gate status before deploying transformations lose their integration surface. Vigilmon gives you external visibility into Databand's infrastructure: the platform application, REST API, and pipeline tracking service, so you know the moment the pipeline observability platform itself needs attention.
What You'll Build
- An HTTP monitor on the Databand platform application to detect availability failures
- A health-check monitor on the Databand REST API to catch backend degradation
- A monitor on the pipeline tracking service to detect pipeline run history collection failures
- A monitor on your incident notification webhook receiver to verify alert delivery is flowing
- An SSL certificate monitor for your Databand domain
- Alerting that distinguishes platform outages from API degradation and tracking service failures
Prerequisites
- A Databand deployment (IBM Cloud-hosted SaaS or self-managed on-premises/cloud instance)
- The Databand platform accessible via HTTPS
- A webhook receiver endpoint configured to accept Databand pipeline incident notifications
- A free account at vigilmon.online
Step 1: Understand Databand's Service Architecture
Databand is built around several tightly integrated components that work together to provide end-to-end pipeline observability:
| Component | Default port | Role |
|---|---|---|
| Platform application | 443 (HTTPS) | Web UI for pipeline run dashboards, incident management, SLA monitoring, and alert configuration |
| REST API | 443 (HTTPS) | Programmatic access to pipeline run history, anomaly findings, and observability configuration |
| Pipeline tracking service | Internal | Collects run metadata, task durations, record counts, and data quality metrics from connected pipelines |
| Anomaly detection engine | Internal | Compares current run metrics against historical baselines to detect execution and data anomalies |
| Incident notification dispatcher | Outbound | Routes pipeline incident alerts to PagerDuty, Slack, webhook endpoints, and incident management systems |
External monitoring focuses on the platform application, REST API, and pipeline tracking service — the components your data engineers interact with when triaging pipeline incidents and reviewing run history. Pipeline tracking service failures are the most dangerous because they stop Databand from collecting the run metadata that anomaly detection depends on — creating a blind spot where real pipeline failures go undetected.
Step 2: Monitor the Databand Platform Application
The Databand web application is the operational command center for data pipeline reliability: reviewing pipeline run timelines, investigating SLA breaches, comparing current run performance against historical baselines, managing alert rules, and coordinating incident resolution across data engineering and analytics teams:
curl -I https://your-databand-instance.databand.ai
# Returns HTTP 200 with HTML when the platform is healthy
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://your-databand-instance.databand.ai(your Databand Cloud or self-managed instance URL). - Check interval: 60 seconds.
- Response timeout: 15 seconds.
- Expected status:
200. - Keyword:
Databand(present in the page title and application HTML). - Click Save.
This monitor catches:
- Databand application server failures or IBM Cloud infrastructure outages
- Failed platform upgrades that leave the application returning 5xx errors
- Load balancer or reverse proxy misconfigurations blocking access to the platform
- DNS resolution failures for the Databand application hostname
Alert sensitivity: Set to trigger after 1 consecutive failure. When Databand is unavailable, data engineers lose the central interface for monitoring active pipeline runs, SLA breach investigations cannot be conducted through the platform UI, and the collaborative incident management workflow that coordinates remediation between engineers and analytics consumers breaks down.
Step 3: Monitor the Databand REST API
The Databand REST API is the integration backbone that connects pipeline observability to the rest of the data stack — the Databand Airflow operator reports task execution metadata to the API after each run, CI/CD pipelines call the API to check whether a pipeline's data quality gates passed before promoting a dbt model, and custom dashboards pull run history and anomaly findings for aggregated reliability reporting:
curl -H "Authorization: Bearer $DATABAND_TOKEN" \
https://your-databand-instance.databand.ai/api/v1/health
# Returns: {"healthy": true} when the API backend is operational
- Add Monitor → HTTP.
- URL:
https://your-databand-instance.databand.ai/api/v1/health. - Check interval: 60 seconds.
- Response timeout: 10 seconds.
- Expected status:
200. - Keyword:
healthy(present in healthy API responses). - Label:
Databand REST API. - Click Save.
Why monitor the API separately from the platform UI? The Databand web application may continue displaying historical run data even when the API backend is degraded. A failing REST API means Airflow operators that call Databand after each task execution receive errors and may back off or retry indefinitely, CI/CD quality gates that call the API before deploying models cannot retrieve gate status and may either block releases or bypass checks, and any custom Databand integration stops receiving updated run metadata.
Step 4: Monitor the Pipeline Tracking Service
Databand's pipeline tracking service is the component that receives and stores pipeline run metadata from connected orchestration tools — collecting task durations, record counts read and written, data quality check results, and exception traces from Airflow, Spark, dbt, and Kafka pipelines. When this service fails, no new run data is ingested: anomaly detection cannot compare current runs against baselines, SLA monitoring has no fresh run completions to evaluate, and the run history timeline that engineers use for incident investigation stops updating:
curl -H "Authorization: Bearer $DATABAND_TOKEN" \
https://your-databand-instance.databand.ai/api/v1/tracking/health
# Returns tracking service status when the pipeline ingestion service is active
- Add Monitor → HTTP.
- URL:
https://your-databand-instance.databand.ai/api/v1/tracking/health. - Check interval: 2 minutes.
- Response timeout: 15 seconds.
- Expected status:
200. - Keyword:
status(present in tracking service health responses). - Label:
Databand pipeline tracking service. - Click Save.
Why pipeline tracking service monitoring matters: A tracking service failure is operationally deceptive. The Databand platform application continues loading and showing historical run data, so engineers looking at dashboards see a fully operational platform while new pipeline runs are silently not being recorded. Real-time SLA monitoring and anomaly detection stop working immediately — but this is invisible until someone notices that the run history timeline has not updated for an extended period.
Step 5: Monitor Your Incident Notification Webhook Receiver
Databand routes pipeline incident notifications — SLA breach alerts, run failure notifications, anomaly detection findings, and data quality violations — to external incident management systems via webhook integrations. If your webhook receiver becomes unavailable, pipeline incident delivery stops: on-call data engineers stop receiving PagerDuty pages for failed Airflow DAGs, Slack data reliability channels go quiet, and the incident management platform that tracks mean time to recovery for data incidents stops receiving events:
curl https://your-webhook-receiver.example.com/health
# Returns: {"status": "ok"} when the receiver is up
- Add Monitor → HTTP.
- URL:
https://your-webhook-receiver.example.com/health. - Check interval: 2 minutes.
- Response timeout: 10 seconds.
- Expected status:
200. - Keyword:
ok. - Label:
Databand incident webhook receiver. - Click Save.
For PagerDuty integrations that route Databand pipeline incidents to on-call engineers, verify https://events.pagerduty.com/v2/health to confirm the PagerDuty events API is reachable. For ServiceNow integrations used to create incident tickets for SLA breaches, monitor that service's health endpoint. For IBM Watson AIOps integrations in IBM Cloud deployments, verify the relevant IBM Cloud service endpoints as well.
Step 6: Monitor SSL Certificates
Databand's platform application and REST API are accessed over HTTPS by data engineers, Airflow operators running in production environments, and CI/CD pipeline scripts. An expired certificate blocks browser access to the incident management UI at the worst possible moment — during an active pipeline incident — and causes Airflow operators to fail with TLS certificate errors, preventing run metadata from being reported to Databand at all:
openssl s_client -connect your-databand-instance.databand.ai:443 2>/dev/null | openssl x509 -noout -dates
- Add Monitor → SSL Certificate.
- Domain:
your-databand-instance.databand.ai(or your self-managed Databand hostname). - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
Self-managed deployment consideration: For Databand deployments hosted in a customer-managed Kubernetes cluster or on-premises environment, TLS certificates are managed by the customer's infrastructure team. Vigilmon's 30-day pre-expiry alert gives the data platform team sufficient runway to coordinate certificate renewal with the infrastructure team before an expiry event blocks pipeline observability at a time when the team's attention is occupied by active data incidents.
Step 7: Configure Alerting
In Vigilmon under Settings → Notifications, configure your alert channels:
| Monitor | Trigger | Action |
|---|---|---|
| Platform application | Non-200 or Databand missing | Check application server; review Databand platform status |
| REST API | Non-200 or healthy missing | API down; Airflow operators and CI/CD quality gates failing |
| Pipeline tracking service | Non-200 or status missing | Run metadata ingestion stopped; SLA and anomaly detection blind |
| Incident webhook receiver | Non-200 or ok missing | Pipeline incident notifications not delivering; check receiver deployment |
| SSL certificate | < 30 days to expiry | Renew certificate; coordinate with infra team for self-managed deployments |
Alert after: 1 consecutive failure for the application, API, and pipeline tracking service monitors. 2 consecutive failures for the webhook receiver to reduce noise from brief transient timeouts.
Common Databand Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor | |---|---| | Platform application failure | Application monitor fires; incident triage dashboard inaccessible | | REST API degradation | API monitor fires; Airflow operators and CI/CD quality gates fail | | Pipeline tracking service failure | Tracking monitor fires; run metadata not ingested; SLA and anomaly detection stop | | Incident webhook receiver crash | Webhook monitor fires; on-call engineers stop receiving pipeline incident alerts | | TLS certificate expired | SSL monitor alerts at 30-day threshold; browser and Airflow operator clients fail | | DNS misconfiguration | All monitors fire simultaneously | | Anomaly detection engine failure | Tracking monitor may fire; ML-based anomaly alerts stop generating | | Database connectivity failure | Application and API monitors fire with 5xx errors | | Failed platform upgrade | Application monitor fires; platform returns errors during rollback | | IBM Cloud infrastructure event | Application and API monitors fire; IBM Cloud status page should be checked |
Monitoring Pipeline Reliability Quality Itself (Beyond Infrastructure)
Vigilmon monitors Databand's infrastructure endpoints — the platform application, REST API, pipeline tracking service, and your incident notification webhook receiver. The quality of pipeline observability coverage — which Airflow DAGs have Databand tracking enabled, whether anomaly detection baselines are calibrated correctly, and whether SLA thresholds reflect actual business requirements — is a separate concern managed within Databand itself:
- Pipeline instrumentation coverage: Regularly audit which pipelines have Databand tracking operators installed. Pipelines that have not been instrumented with the Databand Airflow operator or SDK will not be tracked even when the platform is fully healthy. Coverage gaps are observability blind spots.
- Baseline calibration: Databand's anomaly detection models build baselines from historical run data. After major pipeline refactors or seasonal data volume changes, baselines should be reviewed and reset to prevent false positives from noisy alerts or false negatives from thresholds that no longer match current run characteristics.
- SLA threshold reviews: SLA windows configured in Databand should be reviewed after pipeline architecture changes. An SLA that was appropriate for a batch pipeline may not be appropriate after the pipeline is migrated to near-real-time processing, and stale SLA thresholds generate either excessive alerts or missed breaches.
Vigilmon catches infrastructure-level failures — when Databand itself is down or its tracking service has stopped ingesting pipeline metadata. Improving observability coverage, calibrating anomaly detection baselines, and tuning SLA thresholds within a healthy Databand deployment require configuration and review work within Databand's observability platform.
Databand is the reliability layer that watches your data pipelines for failures, SLA breaches, and data quality anomalies — when the platform goes down or its tracking service stops ingesting run metadata, pipeline failures propagate silently into downstream reports while on-call engineers have no visibility and no alerts. Vigilmon gives you external visibility into Databand's own availability that doesn't depend on Databand self-reporting: platform uptime, API health, pipeline tracking service status, and SSL certificate validity, so you know the moment the pipeline observability platform needs attention and can restore incident management coverage before a real pipeline failure goes undetected by every layer of your data stack.
Start monitoring Databand in under 5 minutes — register free at vigilmon.online.