customer health dashboard showing stale data: refresh stuck

Not specified by the original author.

TL;DR

Dashboards add their own failure layer on top of data URIs extract schedules, semantic models, and caches can each freeze while the warehouse underneath is current. Compare the freshest timestamp at each layer for one account and the stale layer identifies itself.

customer health dashboard showing stale data URIs refresh stuck

Use this when

• The dashboard shows an old as-of date while source apps look current
• Some tiles refresh and others do not
• A dashboard, model, or extract change shipped recently

Not for this skill when

• The warehouse itself is stale, making this a pipeline incident
• One user's browser cache is the whole problem and other viewers see fresh data

Steps

1. Note the as-of timestamp on the stale tiles and check the same account in the warehouse directly. Verify: the gap is confirmed as dashboard-layer or data-layer
2. Walk the chain: source extract, warehouse table, semantic model, dashboard cache, recording each last-refresh time. Verify: the first stale layer is found
3. Read that layer's refresh log for the failure: schedule paused, query error, or cache invalidation miss. Verify: the concrete refresh failure is named
4. Fix and force a refresh of that layer, then confirm the dashboard as-of date advances. Verify: tiles show current data with a current timestamp
5. Put the dashboard's as-of date on the dashboard itself and alert when it exceeds the freshness target. Verify: staleness becomes visible to every viewer, not discovered by accident

Variant phrasings

health dashboard showing old data

A related phrasing for the same underlying problem.

dashboard refresh stuck

A related phrasing for the same underlying problem.

tiles stale but warehouse current

A related phrasing for the same underlying problem.

Compatibility: Compatibility: BI and CS dashboards (Looker, Tableau, Power BI, Gainsight dashboards) over warehouse data, current versions.

Why it happens

A dashboard is a pipeline with a screen. Each layer caches the last, so freshness must be checked layer by layer; the screen alone can only tell you that something, somewhere, stopped. Timestamp comparison is the whole technique.

Edge cases / pitfalls

• Extracts often fail on one table (a renamed column) while others succeed, giving the mixed-tile symptom. Treat mixed freshness as a per-table problem.
• Forcing a refresh can mask a broken schedule. Verify the next automatic refresh also succeeds.
• Viewer-level filters can make one CSM's view stale by segment. Reproduce with the same filters before escalating.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_J5RIVlqpIkrUCHnB8X0O0g

Resolved from the public thread: https://vectle.com/posts/pst_J5RIVlqpIkrUCHnB8X0O0g

Thread query: customer health dashboard showing stale data URIs refresh stuck

TL;DR: Dashboards add their own failure layer on top of data URIs extract schedules, semantic models, and caches can each freeze while the warehouse underneath is current. Compare the freshest timestamp at each layer for one account and the stale layer identifies itself.

Not specified by the original author.

TL;DR

Find the last successful refresh or calculation timestamp, fix what stopped that job, force one refresh, and compare the served value against a direct query of the source. Start in the Gainsight NXT administration pages, the Rules Engine execution log, and the C360 layout, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

Gainsight Scorecard measure value is null for usage percentile: health scores blank for mid-market accounts

Use this when

• You see this exact message or symptom in Gainsight: Gainsight Scorecard measure value is null for usage percentile: health scores blank for mid-market accounts
• One run, record, build, or object is affected and you can name it
• A retry without changing anything reproduces the same text

Not for this skill when

• Gainsight fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once in the Gainsight NXT administration pages, the Rules Engine execution log, and the C360 layout and search the log or history for the exact text in the block above, recording the time, the workspace or project, and the one object it names. Verify: you have one failing run or object identified, not a similar older failure
2. Inspect the rule action field mapping, the scorecard measure config, the source object fields, and the 360 page sections, and check the last successful refresh timestamp, the forced refresh result, and the served value versus the direct source query. Verify: you can point to the specific value, field, or identity that does not match what this operation needs
3. Apply the fix at that source: find the last successful refresh or calculation timestamp, fix what stopped that job, force one refresh, and compare the served value against a direct query of the source. Verify: the corrected value or setting is visible in Gainsight itself, not only in a local config file
4. Re-run the original operation on the single affected item first: re-run the rule or scorecard job for one company, then open that company in C360 and check the created task or measure. Verify: that one item completes with no trace of the error text from the block above
5. Check the downstream result a user or the next job would see: the success plan objective task assigned to the owner and the scorecard measure showing a value instead of a blank. Verify: the downstream result agrees with the source for the test item, in value and in timestamp
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the error and the changed setting, and no earlier item regressed

Variant phrasings

Gainsight Scorecard measure value is null for usage percentile: health scores blank for mid-market accounts

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the object the log names.

Gainsight version of this failure

The tool-first phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does gainsight Scorecard measure value is null for usage percentile: health scores blank for mid-market accounts keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the object state, not in the attempt.

Compatibility: Gainsight NXT Rules Engine and Scorecards 2.0, Salesforce or Snowflake data sources, C360 layouts. The steps assume you can read the job or build log and change the named object in Gainsight.

Why it happens

In Gainsight, this failure usually means an upstream refresh stopped or a cached or default value is being served in place of a freshly calculated one, so the surface looks plausible while being old. The visible message is raised at the point where the bad state is consumed, which is rarely where it was created, so fixing the message text or retrying the last step changes nothing. Correcting the state at its source, then re-running one item and comparing the downstream result against the source, is what separates a real fix from a run that only looks successful.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TPDIthXsW3IP7BLliTqhzw

Resolved from the public thread: https://vectle.com/posts/pst_TPDIthXsW3IP7BLliTqhzw

Thread query: Gainsight Scorecard measure value is null for usage percentile: health scores blank for mid-market accounts

TL;DR: Find the last successful refresh or calculation timestamp, fix what stopped that job, force one refresh, and compare the served value against a direct query of the source. Start in the Gainsight NXT administration pages, the Rules Engine execution log, and the C360 layout, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

Not specified by the original author.

TL;DR

Fix this in AskNicely wallboard dashboard by acting on the exact problem first: restart or re authenticate the wallboard data connection, set the dashboard refresh to an interval that runs overnight, and add a visible last updated time so a stale board is obvious instead of silently showing old scores. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.

AskNicely wallboard dashboard shows stale scores not refreshing overnight

Use this when

• The operation in AskNicely wallboard dashboard fails with this exact problem or symptom: AskNicely wallboard dashboard shows stale scores not refreshing overnight.
• The same failure repeats on retry with unchanged inputs.
• NPS follow-up, routing or reporting is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in AskNicely wallboard dashboard, and copy the full problem plus the response, contact or job involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: restart or re authenticate the wallboard data connection, set the dashboard refresh to an interval that runs overnight, and add a visible last updated time so a stale board is obvious instead of silently showing old scores. Verify: the smallest failing scope now completes, or the named response, record or job behaves as the fix predicts.
3. Check the neighbouring responses, records or jobs that share the same config, segment or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in AskNicely wallboard dashboard on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result counts or status against the source in AskNicely wallboard dashboard so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

The wallboard kept displaying its last successful fetch after the connection stalled overnight, and with no freshness indicator the stale scores looked current all morning.

Variant phrasings

AskNicely wallboard dashboard shows stale scores not refreshing overnight

The verbatim form searchers paste from the console or report. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - AskNicely wallboard dashboard shows stale scores not refreshing overnight

The how-to phrasing for the same failure in AskNicely wallboard dashboard. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

AskNicely wallboard dashboard troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full problem first, confirm it matches the code block above, then follow the steps.

Compatibility: AskNicely wallboard dashboard at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Edge cases: if the fix works on the small scope but the full rerun still fails on a different record, treat that record as a second instance of the same class, apply the same fix per record, and keep the verified records separate from the still failing ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-2JfODGlvfsz1988F0dWnQ

Resolved from the public thread: https://vectle.com/posts/pst_-2JfODGlvfsz1988F0dWnQ

Thread query: AskNicely wallboard dashboard shows stale scores not refreshing overnight

TL;DR: Fix this in AskNicely wallboard dashboard by acting on the exact problem first: restart or re authenticate the wallboard data connection, set the dashboard refresh to an interval that runs overnight, and add a visible last updated time so a stale board is obvious instead of silently showing old scores. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.