tutorial

Monitoring Stitch Data with Vigilmon: ETL Replication Health, API Availability & Data Warehouse Sync Monitoring

How to monitor Stitch Data cloud ETL service for data replication to data warehouses with Vigilmon — API availability, connection health, replication job monitoring, and SSL certificate validity.

Stitch Data is a cloud ETL service that replicates data from SaaS applications, databases, and APIs into cloud data warehouses — Snowflake, BigQuery, Amazon Redshift, and others — through a catalog of pre-built integrations that handle incremental extraction, schema management, and data type coercion automatically. Stitch's architecture abstracts the complexity of building and maintaining ETL pipelines: you configure a source integration, point it at a destination, and Stitch handles extraction scheduling, incremental bookmarking, schema evolution, and record delivery, writing data into warehouse tables that your analytics and BI tools consume. When the Stitch API becomes unavailable, replication jobs cannot be triggered on demand, replication status cannot be queried by external automation, and any monitoring or orchestration tool that polls Stitch for job completion cannot determine whether the warehouse tables are up to date. When a source connection credential expires, that integration silently stops replicating and the corresponding warehouse tables stop growing without any error visible to the BI tool querying them. When the webhook receiver that captures Stitch replication run events is down, your downstream dbt Cloud runs, Looker PDT refreshes, and data freshness alerts fire against data that may be hours behind its source system. Vigilmon gives your data engineering team external HTTP visibility into the Stitch Data surfaces that keep ETL replication running — the API control plane, your source connection health, your destination endpoint accessibility, and your completion webhook receivers — so you catch failures before they silently stall the warehouse data your analytics stack depends on.

What You'll Build

  • An HTTP monitor on the Stitch Data API to detect platform outages before they block replication scheduling and status queries
  • A monitor on the Stitch sources endpoint to catch degradation in connection health reporting
  • A monitor on your replication completion webhook receiver to verify run success and failure notifications are being delivered
  • A monitor on your destination warehouse endpoint to detect connectivity failures before replication jobs encounter them
  • An SSL certificate monitor for your Stitch Data integration domains
  • Alerting that distinguishes API outages from source connection failures and webhook delivery breakdowns

Prerequisites

  • A Stitch Data account with one or more source integrations configured and replicating to a destination
  • A Stitch Data API access token for programmatic access to replication status and connection health
  • An external health endpoint or webhook receiver that captures Stitch replication events
  • A free account at vigilmon.online

Step 1: Understand Stitch Data's Infrastructure Architecture

Stitch replication jobs run on managed cloud infrastructure, but several surfaces are externally monitorable via the Stitch Connect API and your integration layer:

| Component | Surface | Role | |---|---|---| | Stitch Connect API | HTTPS REST (api.stitchdata.com) | Central control plane; manages sources, destinations, replication | | Sources endpoint | /v4/sources | Lists configured integrations and their connection health | | Destinations endpoint | /v4/destinations | Reports on destination warehouse configuration and connectivity | | Connection check surface | /v4/sources/{id}/last-connection-check | Reports on the most recent source connection test result | | Replication completion webhook | Webhook / Slack / PagerDuty | Delivers replication run success, failure, and schema change events | | Stitch web console | HTTPS | Engineer access to integration logs, replication stats, and error detail |

External monitoring focuses on the Stitch API availability, the sources endpoint, and your webhook receivers — these are where ETL replication failures become externally observable before they propagate into stale warehouse tables and broken analytics. An API outage prevents demand-triggered replications and status queries; a source credential expiry silently stops individual integration replication; a downed webhook receiver leaves dbt Cloud, Looker, and your data freshness alerting scheduling work against tables that haven't been updated.

Step 2: Monitor the Stitch Connect API

The Stitch Connect REST API is the control plane for all ETL replication operations. Every on-demand replication trigger, status query, source connection validation, and destination configuration change flows through api.stitchdata.com. When it becomes unavailable or returns errors, external automation cannot trigger replications, cannot query run status, and cannot validate whether source connections are healthy:

# Test Stitch API availability
curl -H "Authorization: Bearer $STITCH_API_TOKEN" \
  https://api.stitchdata.com/v4/sources
# Returns: [{"id": ..., "name": "...", "type": "..."}] when the API is healthy

# Verify destination configuration
curl -H "Authorization: Bearer $STITCH_API_TOKEN" \
  https://api.stitchdata.com/v4/destinations
# Returns destination configuration; a 200 confirms API availability
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://api.stitchdata.com/v4/sources.
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: id (present in every successful Stitch sources response).
  7. Label: Stitch Data API.
  8. Click Save.

This monitor catches:

  • Full Stitch Data platform outages that halt all replication scheduling
  • Infrastructure incidents affecting the Stitch API control plane
  • Authentication service failures that cause all API requests to return 401
  • Network path changes that have cut off your monitoring infrastructure from the Stitch API

Alert sensitivity: Set to trigger after 1 consecutive failure. A Stitch API outage means no replication can be triggered on demand, no run status can be queried, and no connection health can be validated from any external tool.

Step 3: Monitor the Sources Connection Health Endpoint

The Stitch sources endpoint exposes the configuration and last-connection-check result for each of your source integrations. When a source credential expires — an OAuth token for Salesforce, a database password for Postgres, an API key for Stripe — Stitch cannot extract new records and that integration's warehouse tables stop growing. Monitoring the sources endpoint gives you a signal to check connection health before your analytics team notices that yesterday's data is missing from their dashboards:

# List all source integrations and their configuration
curl -H "Authorization: Bearer $STITCH_API_TOKEN" \
  https://api.stitchdata.com/v4/sources
# Returns: [{"id": ..., "name": "...", "paused": false, "status": "..."}]

# Get the most recent connection check result for a specific source
curl -H "Authorization: Bearer $STITCH_API_TOKEN" \
  https://api.stitchdata.com/v4/sources/YOUR_SOURCE_ID/last-connection-check
# Returns: {"status": "succeeded", "error": null} when credentials are valid
  1. Add Monitor → HTTP.
  2. URL: https://api.stitchdata.com/v4/sources.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: id.
  7. Label: Stitch Data sources endpoint.
  8. Click Save.

Why monitor the sources endpoint separately from the general API? Stitch may experience partial degradation where the top-level API health check responds normally while the sources management surface encounters errors. The sources endpoint can be degraded while the API appears broadly accessible, leaving your monitoring tools unable to determine which integrations are actively replicating.

Step 4: Monitor the Destinations Endpoint

Stitch writes replicated data to your destination warehouse — Snowflake, BigQuery, Redshift, or another target. When the destinations API endpoint is degraded, you cannot verify that your warehouse destination configuration is intact, and any configuration drift (credential rotation, endpoint changes) goes undetected until replication jobs fail at the load stage:

# Check destination configuration and connectivity status
curl -H "Authorization: Bearer $STITCH_API_TOKEN" \
  https://api.stitchdata.com/v4/destinations
# Returns: [{"id": ..., "type": "snowflake", "connection": {...}}]

# Validate specific destination connectivity
curl -H "Authorization: Bearer $STITCH_API_TOKEN" \
  https://api.stitchdata.com/v4/destinations/YOUR_DESTINATION_ID/last-connection-check
# Returns: {"status": "succeeded"} when destination credentials and connectivity are valid
  1. Add Monitor → HTTP.
  2. URL: https://api.stitchdata.com/v4/destinations.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: type.
  7. Label: Stitch Data destinations endpoint.
  8. Click Save.

This monitor detects destination-layer failures that would prevent Stitch from loading replicated records into your data warehouse, giving your team a signal before warehouse tables stop receiving updates.

Step 5: Monitor Your Replication Completion Webhook Receiver

Stitch can emit events — replication run completions, failures, schema changes, and extraction errors — to external webhook receivers that feed your incident management, downstream orchestration, or notification systems. If the webhook receiver is down when a Stitch integration fails due to an API rate limit or source schema change, your dbt Cloud runs proceed against tables that may be hours behind, your Looker dashboards serve stale metrics, and your data freshness SLA alerts never fire:

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

For Slack-based Stitch failure notifications, verify https://slack.com/api/api.test to confirm Slack API reachability from your notification infrastructure. For PagerDuty-routed replication failures, monitor https://api.pagerduty.com/ability to verify the Events API is accessible.

Step 6: Monitor SSL Certificates

The Stitch API is accessed by data engineers during incident response and by automated tools over TLS. An expired certificate on api.stitchdata.com or any custom domain fronting your webhook receiver blocks both human access and automated integrations at the worst possible moment — when a replication run has failed and your team needs to query the Stitch API to understand which integrations are affected and how many hours of data are missing from the warehouse:

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

Repeat for any custom domains fronting your webhook receivers or internal tooling that integrates with the Stitch Connect API. Stitch-managed certificates on api.stitchdata.com are renewed by Stitch Data, but custom webhook domains and internal automation proxies require your team's certificate management.

Step 7: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Stitch Data API | Non-200 or id missing | All on-demand replication and status queries halted; escalate to data engineering | | Sources endpoint | Non-200 or id missing | Integration health invisible; cannot detect credential expiry | | Destinations endpoint | Non-200 or type missing | Warehouse connectivity status unknown; may miss load failures | | Replication webhook | Non-200 or ok missing | Run events not being delivered; dbt and BI tools on stale data | | SSL certificate | < 30 days to expiry | Renew certificate; API access blocked on expiry |

Alert after: 1 consecutive failure for the Stitch Data API. 2 consecutive failures for the sources and destinations endpoints and webhook receiver to reduce noise from brief transient timeouts during Stitch platform maintenance windows.

Common Stitch Data Infrastructure Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Stitch platform outage | API monitor fires; all replication scheduling halted | | Sources endpoint degradation | Sources monitor fires; credential health invisible | | Destinations endpoint failure | Destinations monitor fires; load configuration status unknown | | Source credential expiry | Sources endpoint returns 200 but connection check shows failure | | Destination credential rotation | Destinations monitor healthy but replication load jobs fail | | Webhook receiver crash | Webhook monitor fires; completion events not delivered | | TLS certificate expired on webhook domain | SSL monitor alerts at 30-day threshold | | Control plane maintenance window | API monitor fires during window | | Authentication service degradation | API returns 401; API monitor fires | | Source API rate limiting | Individual replication runs pause; Stitch API and sources endpoint healthy | | Schema change in source | Stitch pauses replication; sources endpoint may show paused status | | Network path to Stitch API blocked | All API monitors fire with connection timeout |

Monitoring Replication Data Quality (Beyond Infrastructure)

Vigilmon monitors the infrastructure that Stitch Data depends on — the API control plane, the sources and destinations health surfaces, and your webhook receivers. The actual completeness of replicated records, the accuracy of incremental bookmarks, and the freshness of what lands in your warehouse require additional observability practices:

  • Replication bookmark accuracy: Stitch tracks an incremental bookmark (a cursor or high-water mark) for each integration to manage incremental extraction. A Stitch integration that succeeds at the API level may have silently advanced its bookmark past records that were delayed in the source system, causing permanent gaps. Infrastructure health cannot detect bookmark drift.
  • Row count monitoring: Track the actual row counts landing in your warehouse tables across Stitch replication runs. An integration that completes successfully but extracts zero records due to a source API filter change or empty extraction window will report completed to the Stitch API — the infrastructure monitor fires green while your tables stop growing.
  • Schema evolution handling: Stitch automatically handles some schema changes, but others cause it to pause a replication and require manual intervention. Monitor your Stitch console for integrations in a paused state due to unsupported schema changes — infrastructure monitors cannot detect a paused integration that appears healthy at the API level.
  • End-to-end data freshness: Track the event timestamp or updated_at field of the most recently replicated record in your critical warehouse tables. A healthy Stitch API does not guarantee that the most recent replication run successfully loaded records — empty extraction windows, source API outages during the extraction window, and destination load errors can all result in stale tables with a healthy-appearing infrastructure.

Vigilmon catches infrastructure failures — when the Stitch API is unavailable, the sources or destinations surface is degraded, or the webhook receiver stops accepting events. The completeness of incremental bookmarks, the accuracy of schema mapping, and the freshness of what lands in your warehouse for downstream dbt and BI consumption require domain-specific data replication quality monitoring layered on top of infrastructure health checks.

Stitch Data brings managed cloud ETL to data teams who need reliable, low-maintenance replication from SaaS applications and databases into modern cloud data warehouses, but the API infrastructure it runs on — the Connect API, the sources and destinations health layer, and your webhook receivers — can fail in ways that silently stall warehouse replication without surfacing visible errors to the BI tools and dashboards consuming the data. Vigilmon gives your data engineering team external visibility into that infrastructure: API availability, sources and destinations endpoint reachability, and SSL certificate validity, so you know the moment Stitch needs attention and can restore replication before warehouse tables drift so far behind their source systems that analytics and decisions are based on stale data.

Start monitoring your Stitch Data replication infrastructure 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