health score not updating after data sync: troubleshooting
Troubleshoots a health score that stops updating after a data sync by finding which stage of the sync-to-score chain stalled. Use when scores freeze at one date. Not for scores updating on a deliberately weekly cadence.
TL;DR
A frozen score has a frozen stage: the source sync, the warehouse load, the scoring run, or the write-back. Each stage leaves a last-success timestamp, and reading them in order shows the first stale one. Fix that stage and the rest usually follow without further surgery.
health score not updating after data sync: troubleshootingUse this when
- All scores carry the same last-updated date
- Source data (usage, tickets) is current in its own system
- A sync, credential, or infrastructure change happened near the freeze
Not for this skill when
- Scores are intentionally computed weekly and the date is within cadence
- Only one account is stale, suggesting an account-level skip instead
Steps
- Record last-success timestamps for source sync, warehouse load, scoring run, and write-back. Verify: the first stale stage in the chain is identified
- Read that stage's most recent error or skip log in full. Verify: the concrete failure (expired credential, schema drift, locked table) is named
- Fix the cause and re-run that stage alone, watching its output land. Verify: the stage completes and its timestamp advances
- Trigger the downstream stages and confirm scores refresh for a sample of accounts. Verify: sampled accounts show new scores and new timestamps
- Alert on stage freshness: any stage older than its cadence plus a grace window pages the owner. Verify: the next freeze is caught by alert, not by a CSM noticing
Variant phrasings
health scores frozen at one date
A related phrasing for the same underlying problem.
score not updating after sync
A related phrasing for the same underlying problem.
scoring pipeline stalled stage
A related phrasing for the same underlying problem.
Compatibility: Compatibility: chained sync and scoring jobs (Airflow, Fivetran-style syncs, CRM write-back), current versions.
Why it happens
Chains fail at one link but present as a dead end metric. Last-success timestamps turn the chain into a row of clocks; the first stopped clock is where the work is, and later clocks are innocent by construction.
Edge cases / pitfalls
- A stage can succeed while writing zero rows (source filter changed). Check row counts, not only success status.
- Credential expiries often hit several stages days apart. Rotate the shared credential everywhere once found.
- Re-running a frozen chain can double-write scores if write-back is not idempotent. Check before the catch-up run.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_WFrfx6QEa4l1kQxXNa9ChA