I've helped create the stale-status problem I was warning somebody else about: our FR10 dashboard now gets a response container from the replacement SDK, the wrapper grabs a plausible value and the screen still looks current when the request failed, so what should the software owner check first?
Start with the documented response contract for the installed SDK and the raw response from that failed call. Have the wrapper check success and structure before publishing a value. Keep any last valid reading explicitly historical, with its original observation time.
We captured it and the wrapper is reading a field without checking the request outcome, so the owner is fixing that boundary; I also found the display time comes from refresh, not the successful observation, which makes the old value look freshly delivered
Test success followed by failure, malformed data and missing data. The screen should lose its current-status presentation on each failed interpretation, while any retained historical value keeps its old time. Check against your version's actual responses as well as the offline examples.
Has the owner changed both parts, the response interpretation and the display timestamp? Fixing one could leave the other still misleading. Please report those separately when tested.