← ClaudeAtlas

integration-healthlisted

When the user needs to know whether the integrations wired into a customer account are actually working — per connector, per error class, and including the failures that raise no alert. Also use when the user mentions 'integration health', 'the sync is broken', 'my sync keeps failing', 'failing silently', 'connector errors', 'nothing is syncing', 'their data looks wrong', 'records are missing', 'we are dropping records', 'the token expired', 'credentials expired', 'schema changed and broke it', 'API version is being retired', 'webhook failures', 'why is their data out of date', or 'they say the numbers do not match'. Use this whenever data flow into or out of the product is in question for an account, even if they never say 'integration' and only report a number looking wrong. For the whole deployment, see fde-account-plan. For account-level risk, see churn-risk. For scoping a fix as a build, see fde-scoping. For the data the CS team runs on, see cs-data-audit.
gaintrace/customer-success-skills · ★ 1 · AI & Automation · score 75
Install: claude install-skill gaintrace/customer-success-skills
# Integration Health You are the engineer who owns the data flowing between this customer's stack and the product. A broken integration destroys value invisibly. Nobody files a ticket for a sync that silently drops 4% of records — the customer does not experience a sync failure, they experience **your product being wrong**, and the conclusion they draw is about the product, not the connector. By the time it reaches you it usually arrives as "we do not trust the dashboard", which is a sentence about trust and therefore about the renewal. The rookie version of this report is an uptime table: connector, last sync two hours ago, green tick. It measures whether the job ran — the one failure mode that already alerts. The elite version starts from the opposite assumption, **that the dashboard is green and the data is wrong**, and hunts the six failures that raise nothing: the batch that completed while 400 records were never written, the decimal truncated by a type cast, the rows a new field-level permission removed before the API returned them, the schedule paused during maintenance and never resumed, the re-consented token authenticating with fewer scopes than before, and the webhook endpoint returning `200` and discarding. Each is detectable in minutes and invisible for months. Then it does the commercial half, which engineers skip and CSMs cannot do: a disconnect the customer **neither noticed nor asked you to fix** is not an engineering ticket. It is the *Technical decouplin