auditing-warehouse-source-health

This skill produces a project-wide audit of the source and sync side of the data warehouse pipeline — source connections, sync schemas, and webhook push channels. Use it when the user wants a summary of what's broken with their imports, not a deep-dive on one sync. The deep-dive on individual failures is diagnosing-failed-warehouse-syncs; this skill is the scan that tells them where to look first.

The same underlying endpoint (data-warehouse-data-health-issues-retrieve) also reports materialized-view, batch-export-destination, and transformation issues. Materialized views are covered by auditing-warehouse-view-health. Destinations (batch exports) and transformations are owned by other products — surface them if they appear, but route them to the relevant team rather than diagnosing here.

• "Why are my imports failing?" / "What's broken with my sources?"
• "Why is my warehouse data stale?"
• The user is new to a project and wants to know which sources they've inherited and whether they're healthy
• Weekly or monthly review of source/sync health
• Dashboards are stale and the user isn't sure which source is at fault

The data-health-issues endpoint aggregates across the whole pipeline — it's the fastest path to a summary. Filter its results to the source and external_data_sync types for this audit. Use the list endpoints when you need more context than the summary provides (row counts, non-failing items, schema-level detail).

From the data-health endpoint, this audit cares about two of the five categories:

Each entry includes id, name, type, status, error, failed_at, url, and source_type.

The other categories the endpoint returns are out of scope for this skill:

• materialized_view → auditing-warehouse-view-health
• destination (batch export) → owned by the batch exports / data pipelines product
• transformation (HogFunction) → owned by the CDP / ingestion side

Note the data-health endpoint only reports active failures. For source/sync health it doesn't flag:

• Schemas paused by the user (should_sync = false)
• Schemas that are slow or stale but technically Completed
• Webhook problems on sync_type: "webhook" schemas. The bulk-sync safety net can succeed while the webhook push channel is silently broken (deregistered, disabled on the remote side, failing signature verification). These don't surface in data-health-issues — check per-source with webhook-info-retrieve.

If the user asks about staleness or unused items, reach beyond this endpoint — see Step 4.

• The audit is read-only. Never call destructive tools from the audit flow. Hand off to the diagnosis/tuning skills — which in turn confirm before acting.
• Empty = healthy. Don't pad an empty audit with hypothetical issues. "No source issues found" is a good answer.
• Source failures cascade. When reporting a source in Error, also mention which schemas under it are affected (or will be, once they try to sync again). The user needs to understand the blast radius.
• Billing limits aren't technical problems. Flag them but route to billing / quota discussion, not to a recovery action.
• data-health-issues only surfaces active failures. For staleness or abandoned sources you need to cross-check the list endpoints. Only do this when the user explicitly asks for a deeper audit.
• Webhook health is separate from schema health. The data-health endpoint doesn't know about webhook state. When a user's request mentions "real-time", "Stripe webhook", or "why is data hours behind on a webhook source", go straight to webhook-info-retrieve rather than inferring from schema status.
• Materialized views, destinations, and transformations are out of scope here. They share the data-health endpoint but belong to other audits/products — route, don't diagnose.