Sometimes we can define a manual input data tag that does not change frequently (let's say twice a year), in this case we will see this tag as a stale tag, however the value is correct and the tag does not have any problem.
To be brief, yes. A "Stale" point could be correct, and the use case you outline is fairly common.
Our software is designed with scale in mind, and we recognize that managing (up to) millions of tags at a time can be quite a challenge. The "Stale" property of a tag is really only a way of highlighting something that might require your attention, and it errs on the side of caution.
In the case of a manual input tag, there's no information available to the software for when it should "expect" the next data point to come in. Seeing no new data for several months might indicate that the tag is no longer being used, that the tag updates very slowly, or something else entirely. Because we cannot differentiate these cases programmatically we present all "Stale" points to our customers, and we ask that they take any appropriate action (alongside our Support team if necessary).
First, see Andrew's response, I agree with his response.
Second, I have seen instances of people trying to reduce archive usage by defining tags as snapshot only - no archiving for infrequently changing data, or data that is 'constant'.
To borrow the expression, "It's all fun and games until someone get's hurt", if something happens to the archive and SnapFix is executed, that snapshot value is gone with no history as to what it was.
Please, allow ALL tags to archive, even if very infrequently.
Retrieving data ...