Anomalo is the AI-powered data quality platform that uses machine learning to automatically detect anomalies in your data warehouse tables without requiring teams to write manual rules for every column. It infers expected distributions, identifies schema drift, and surfaces data incidents before they propagate into dashboards, models, and downstream systems. When Anomalo's backend goes down, automated anomaly detection stops running and data quality checks are silently skipped. When the API is degraded, integrations that check data quality status before triggering pipeline steps fail, letting potentially bad data flow into production. Vigilmon gives you external visibility into Anomalo's platform availability: the API, dashboard, and alert notification pipeline, so the observability layer itself never becomes a blind spot.
What You'll Build
- An HTTP monitor on the Anomalo dashboard to catch frontend failures
- A health-check monitor on the Anomalo API to detect backend degradation
- A monitor on alert notification delivery to verify Slack/PagerDuty integrations are flowing
- An SSL certificate monitor for your Anomalo domain
- Alerting with appropriate thresholds for each component
Prerequisites
- An Anomalo account (cloud-hosted SaaS or private deployment)
- The Anomalo dashboard accessible via HTTPS (e.g.,
https://your-org.anomalo.com) - Alert notifications configured to a Slack channel, PagerDuty, or custom webhook
- A free account at vigilmon.online
Step 1: Understand Anomalo's Service Architecture
Anomalo's platform consists of several layers:
| Component | Access point | Role | |---|---|---| | Anomalo Dashboard | HTTPS (web UI) | Alert review, table configuration, anomaly investigation | | Anomalo REST API | HTTPS | Check scheduling, alert queries, integration triggers | | ML inference engine | Internal | Computes expected distributions and scores anomalies | | Notification dispatcher | Outbound | Delivers alerts to Slack, PagerDuty, email, and webhooks | | Warehouse connector | Outbound to warehouse | Queries Snowflake, BigQuery, Databricks, Redshift for table metrics |
External monitoring focuses on the dashboard and API HTTPS endpoints — these represent the availability of the entire Anomalo deployment and are the surfaces your team interacts with during data incidents.
Step 2: Monitor the Anomalo Dashboard
The Anomalo dashboard is where data engineers investigate open anomalies, review alert history, and configure which tables Anomalo is watching:
curl -I https://your-org.anomalo.com
# Returns HTTP 200 with HTML when the dashboard is healthy
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://your-org.anomalo.com. - Check interval: 60 seconds.
- Response timeout: 15 seconds.
- Expected status:
200. - Keyword:
Anomalo(appears in the page title and content). - Click Save.
This monitor catches:
- Anomalo frontend process crashes or deployment failures
- Reverse proxy or load balancer misconfigurations
- DNS resolution failures for your Anomalo subdomain
- Failed Anomalo upgrades that leave the frontend broken
Alert sensitivity: 1 consecutive failure. When the dashboard is unavailable during a data incident, engineers cannot review which tables triggered anomalies or what the detected pattern looks like, slowing incident response significantly.
Step 3: Monitor the Anomalo REST API
Anomalo's API powers automated workflows — pipeline orchestrators (Airflow, Prefect, dbt) call Anomalo's API to gate downstream tasks on data quality before proceeding:
curl https://your-org.anomalo.com/api/v1/ping
# Returns: {"status": "ok"} when the API is responsive
- Add Monitor → HTTP.
- URL:
https://your-org.anomalo.com/api/v1/ping. - Check interval: 60 seconds.
- Response timeout: 10 seconds.
- Expected status:
200. - Keyword:
ok. - Label:
Anomalo API health. - Click Save.
Why this matters for pipelines: Data teams often configure Airflow or dbt Cloud to call Anomalo's API and check for active anomalies on source tables before running transformations. When the API is down, these gate checks either fail (blocking the pipeline entirely) or are skipped (letting potentially degraded data flow through). Knowing the API is down before pipeline failures surface saves significant debugging time.
Step 4: Monitor the Anomalo Check Run Endpoint
Anomalo exposes an endpoint that reports the status of recently executed checks — whether anomaly detection jobs ran successfully and when the last check completed:
curl -H "Authorization: Bearer <api_token>" \
"https://your-org.anomalo.com/api/v1/checks/recent"
# Returns recent check run status and timestamps
- Add Monitor → HTTP.
- URL:
https://your-org.anomalo.com/api/v1/checks/recent. - Method:
GET. - Headers: Add
Authorization: Bearer <your-api-token>. - Check interval: 5 minutes.
- Response timeout: 15 seconds.
- Expected status:
200. - Keyword:
check_id(present in successful check run responses). - Label:
Anomalo check runs. - Click Save.
This catches cases where the Anomalo API is reachable but the ML inference engine or warehouse connectivity has silently failed, causing checks to stop executing without surfacing an obvious error.
Step 5: Monitor Your Alert Notification Endpoint
Anomalo delivers data quality alerts to your on-call tools via outbound webhooks. When the notification dispatcher fails or your receiver is down, anomaly alerts stop reaching your team. Monitor your webhook receiver:
curl https://your-alert-receiver.example.com/health
# Returns: {"status": "ok"} when the receiver is accepting events
- Add Monitor → HTTP.
- URL:
https://your-alert-receiver.example.com/health. - Check interval: 2 minutes.
- Response timeout: 10 seconds.
- Expected status:
200. - Keyword:
ok. - Label:
Anomalo alert receiver. - Click Save.
For Slack-based notifications, you can verify the Slack API availability at https://slack.com/api/api.test as a proxy for whether Anomalo's Slack alerts would succeed.
Step 6: Monitor SSL Certificates
Anomalo's API is accessed programmatically by Airflow, dbt, and custom pipeline scripts. An expired certificate breaks these connections silently — pipelines may start skipping Anomalo quality gates or logging TLS errors without surfacing a clear root cause:
openssl s_client -connect your-org.anomalo.com:443 2>/dev/null | openssl x509 -noout -dates
- Add Monitor → SSL Certificate.
- Domain:
your-org.anomalo.com. - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
Programmatic client impact: Anomalo API clients in Airflow DAGs, dbt test callbacks, and Python data pipeline scripts will throw SSL verification errors when the certificate expires. These errors typically surface as confusing pipeline failures rather than clearly pointing to certificate expiry — certificate monitoring prevents that diagnostic confusion.
Step 7: Configure Alerting
In Vigilmon under Settings → Notifications, configure your alert channels:
| Monitor | Trigger | Action |
|---|---|---|
| Dashboard | Non-200 or Anomalo missing | Check frontend deployment; inspect proxy/CDN configuration |
| API health | Non-200 or ok missing | Backend API down; check Anomalo service status; verify database connectivity |
| Check runs | Non-200 or check_id missing | Inference engine stalled; check warehouse connectivity from Anomalo workers |
| Alert receiver | Non-200 or ok missing | Notifications not delivering; verify receiver deployment; check webhook configuration |
| SSL certificate | < 30 days to expiry | Renew certificate; verify API clients reconnect successfully |
Alert after: 1 consecutive failure for the dashboard and API health monitors. 3 consecutive failures for check runs (5-minute interval) to avoid noise from temporary warehouse query timeouts.
Common Anomalo Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor | |---|---| | Anomalo API process crash | API health monitor fires; pipeline quality gates start failing | | Dashboard deployment failure | Dashboard monitor fires; engineers cannot investigate open anomalies | | ML inference engine stalled | Check run monitor fires; anomaly detection silently stops | | Warehouse connectivity lost | Check run monitor fires; Anomalo cannot pull table metrics | | Alert receiver down | Alert receiver monitor fires; on-call team stops receiving notifications | | TLS certificate expired | SSL monitor alerts at 30-day threshold; API clients throw TLS errors | | DNS misconfiguration | All monitors fire simultaneously | | Anomalo upgrade breaks API routing | API health and check run monitors fire after failed deployment |
Monitoring Data Quality Results (Beyond Infrastructure)
Vigilmon monitors Anomalo's infrastructure — the API, dashboard, and notification pipeline. The health of individual anomaly detections is managed within Anomalo itself:
- Anomalo's alert policies: Configure sensitivity thresholds and routing rules within Anomalo to control which anomalies generate alerts and where they go.
- Table coverage auditing: Periodically review which warehouse tables have Anomalo checks configured to ensure new tables are onboarded before data quality issues accumulate.
- Warehouse query performance: Anomalo's check execution speed depends on your warehouse query performance. Slow checks may indicate resource contention in your warehouse rather than Anomalo infrastructure failures.
Vigilmon catches infrastructure-level failures — when Anomalo itself is unavailable. Anomaly detection quality requires tuning within Anomalo's configuration.
Anomalo's value comes from continuous, silent monitoring — it watches your tables on a schedule and only surfaces when something looks wrong. That silence is valuable only when you know the platform is actually running. Vigilmon gives you external visibility into Anomalo's availability that doesn't depend on Anomalo self-reporting: API uptime, dashboard health, check execution status, and SSL certificate validity, so you know immediately when the AI-powered quality layer needs attention and can restore coverage before the next data incident goes undetected.
Start monitoring Anomalo in under 5 minutes — register free at vigilmon.online.