Status light stays green after a failed job

Status Light is a desk indicator with red, amber and green lenses that needs a configured integration to represent software activity. If it remains green after a job fails, investigate the state pipeline before trusting the colour. The lamp can only show the command it receives; a previous success can remain visible when a later event is missed or interpreted incorrectly.

Did the source report the failure you expected?

Open the authoritative job record and confirm its identity, attempt and final result. A failed step may belong to a different run from the one your integration tracks. Record the relevant identifier so the investigation follows one task rather than comparing unrelated events.

Inspect whether your subscription includes the event and action associated with completion. For a GitHub-based source, the webhook best-practice guide explains why event type and action need explicit handling. Receiving some repository activity is not proof that the required failure event was processed.

Where did the update stop?

Follow the event from provider delivery to receiver log, interpreted state and attempted device update. Keep those stages distinct. A successful HTTP response from your receiver may mean only that it accepted the request, especially if processing continues through a queue.

Log the job reference, interpreted outcome and update result without storing unnecessary payload content. If the receiver saw failure but the state remained success, inspect the mapping logic. If the state changed but no device command was attempted, investigate the bridge between application state and hardware control.

Could an older success have overwritten the result?

Compare the task identity and event version or ordering information used by the integration. A delayed completion from an earlier attempt should not automatically replace the result of the current attempt. Define which task the display represents before deciding which update is newer.

Do not solve this by declaring every received event authoritative. Store enough state to reject irrelevant or superseded updates. If ordering cannot be established, display uncertainty through a supported convention and consult the source instead of presenting a confident success signal.

What confirms the repair?

Use a controlled test source or recorded non-sensitive event fixture to exercise success, failure and an ignored older event. Check the internal state and the visible device result separately. Use only the control method documented for the actual hardware; this guide does not establish a particular protocol.

The Status Light product information describes the physical indicator. A reliable green signal requires an integration that handles current task identity, failure events and unsuccessful updates explicitly.