Distinguish a failed notification from a failed build

Status Light is a desk indicator controlled by an integration with your work tools. If an update fails to reach it, that is evidence about notification delivery, not necessarily the build itself. Keep those outcomes separate in logs and in the visible convention. Otherwise a disconnected device can appear to report a broken build, while a stale success can hide a real failure.

What does the build source report?

Open the authoritative run record and confirm the selected revision, attempt and final outcome. Use its actual state rather than inferring success from a notification appearing or failure from one being absent. A build can finish correctly even when every downstream notification attempt fails.

Record the source identity alongside the interpreted result. If the integration tracks several builds, make sure you are comparing the same run throughout the investigation. A recent failure in another branch can be valid information without explaining this particular desk signal.

Where did notification delivery fail?

Inspect the route from source event to receiver, processing worker and device-control step. A receiver may acknowledge a request before the worker finishes, so successful transport to that endpoint does not establish successful output at the desk.

Give each stage a distinct diagnostic result. A validation rejection, a parsing error and an unavailable device require different corrections. Avoid a single generic failed field that overwrites the build outcome with whichever notification problem occurred most recently.

How should the display express uncertainty?

Retain the last known build result while marking its delivery or freshness as uncertain in the companion view. Choose a supported physical convention that does not present the old state as freshly confirmed. If the lamp cannot communicate the distinction clearly, let the text status carry it.

Do not assume the device reports its actual visible state back to the bridge. If your confirmed interface only allows writes, describe the result as an accepted or attempted command according to the evidence available. Keep that limitation explicit in the integration's health checks.

What repair should be tested?

Exercise a successful source result with a deliberately unavailable test device path, then a failed source result with working delivery. Both cases should preserve the source outcome while reporting the notification result independently. Check recovery without rerunning the original build solely to make the lamp change.

The Status Light product overview describes the physical signal unit. A trustworthy integration needs separate records for what happened in the job and whether the desk successfully received the information, plus a clear route back to the authoritative run.