Choose a timeout for stale status information
Status Light can show a task signal through software that translates source activity into device updates. That signal needs a freshness rule if it can remain visible after updates stop. A timeout defines when the integration no longer considers its evidence current. Choose the rule from the workflow's actual update pattern rather than copying an arbitrary duration into every setup.
What event refreshes the timer?
Decide whether freshness means the source was successfully checked, a relevant task update arrived or the device confirmed an output change. These observations prove different things. A heartbeat from a local process does not establish that the remote job state was refreshed.
Keep separate timestamps when more than one boundary matters. Name them precisely in diagnostics so a recent device write cannot conceal an old source observation. The display policy can combine those facts later, but the underlying evidence should remain distinguishable.
How often should new evidence arrive?
Inspect the source's normal behaviour. An event-driven job may remain running for a long period without emitting another event, while a polling integration expects regular responses. Silence alone has different meanings in those two arrangements.
For event-driven work, consider a separate liveness or reconciliation check instead of declaring a legitimate long task stale solely because it has not finished. For polling, account for ordinary request delays and transient errors. A timeout should detect meaningful uncertainty without turning routine jitter into constant visual changes.
What happens when evidence expires?
Represent stale information as uncertainty about the present state. Do not convert it into a failed job unless the source actually reports failure. Retain the last known outcome for diagnosis, while ensuring the visible convention does not imply it was just verified.
Use output states confirmed by the hardware's control method. If the physical signal cannot express age and outcome clearly, provide a text companion with the last-check time and source link. Avoid inventing a flashing mode or feedback capability to make the design look complete.
How should the threshold be validated?
Observe a representative workflow, then test delayed responses, a stopped bridge and recovery after an outage. Check that the timeout responds to the intended missing evidence and that recovery requires a fresh observation. Simply restarting a timer should not make an old cached success current again.
Document the reason for the chosen duration and revisit it when update frequency or task expectations change. The Status Light product information explains the desk indicator; freshness is a software policy that needs evidence, explicit expiry behaviour and a tested recovery path.