用途：该技能产出 PostHog 项目数据仓库导入侧的全局审计，覆盖来源连接（source connections）、同步 schema（sync schemas）与 webhook 推送通道。适合用户问“为什么我的导入失败”“哪些来源坏了”“仓库数据为什么过期”，或接手新项目需了解继承来源是否健康、做周度或月度健康复查时使用。若只针对单个同步做深入排查，应交给 diagnosing-failed-warehouse-syncs，本技能负责先找出该看哪里。
可用工具：data-warehouse-data-health-issues-retrieve（一次拉取整条流水线的失败/降级项，取其中 source 与 external_data_sync 两类）；external-data-sources-list（所有来源的状态与最近错误）；external-data-schemas-list（schema 的状态、last_synced_at、latest_error）；external-data-sources-webhook-info-retrieve（逐来源检查 webhook 状态）。
判定口径：source 对应 ExternalDataSource.status = Error（整条来源连接断开，优先级高）；external_data_sync 对应 schema 处于 Failed 或 BillingLimitReached（data-health 返回 status 为 failed 或 billing_limit）。每条含 id、name、type、status、error、failed_at、url、source_type。materialized_view、destination、transformation 不属于本技能范围，需路由到对应审计或产品。
流程：先一次性拉取并保留 source 与 sync 项，无问题即告知来源健康，不臆造问题；再按优先级分组（来源 Error 优先，因其下所有 schema 实际中断；其次同步 schema，顺序为 billing_limit、高频表失败、低频表失败）；然后输出按类别分组的可读报告而非原始 JSON，并给出建议处理顺序；最后提供下一步交接，如深入 Stripe 失败、修复 schema 漂移或停用超限 schema。
限制：审计为只读，绝不调用破坏性工具，也不自动执行修复，任何修复须显式确认。data-health 端点只报活跃失败，不覆盖被暂停（should_sync = false）、缓慢或过期但状态仍为 Completed 的 schema，也不覆盖 webhook 问题——webhook 需用 webhook-info-retrieve 单独检查（如 exists: false、external_status.error 存在、external_status.status 非 enabled）。深层核查（陈旧但 Completed 的 schema、零同步活动的来源、失效 webhook）仅在用户明确要求更广审计时执行，且会带来更多工具调用与启发式判断。计费限制属非技术问题，应标记并转给计费/配额渠道。