Status light does not change when a webhook arrives

Status Light presents a physical desk signal through a user-configured software integration. When a webhook arrives but the light does not change, divide the investigation into receiver behaviour and device delivery. An incoming request is only the beginning of the route. It must be accepted as valid, interpreted as a relevant event and translated into a supported hardware action.

Was the delivery actually accepted?

Inspect the provider's delivery record and your receiver's response. Confirm that the request reached the expected endpoint rather than a redirect, login page or unrelated service. A network-level success can still conceal an application that ignored the payload.

If validation failed, investigate the configured secret and the receiver's documented verification process without logging secret values. GitHub's delivery-validation documentation describes verifying its webhook signatures. Keep validation intact while diagnosing; allowing arbitrary requests would change the meaning of a trusted status signal.

Did the handler recognise the event?

Record the event type, action and relevant task identity. Check the branch of code that decides whether this event should affect the display. Some events legitimately produce no change, such as activity from a different repository or an update unrelated to the chosen task.

Make ignored events distinguishable from parsing errors in the diagnostic log. Otherwise, a deliberate filter and a broken payload interpretation can look identical. Keep the log focused on routing decisions rather than dumping complete payloads that may contain private project information.

Did processing continue after the response?

If the receiver acknowledges first and uses a queue, inspect the queued job and worker result. A quick acknowledgement helps the provider complete delivery, but it does not establish that the worker finished. Check retries and terminal failures in the component that actually sends the device update.

Confirm the desired state changed before investigating the lamp. If the software already believed the display matched that state, it may have suppressed an unnecessary command. Determine whether that belief is based on confirmed device state or merely the last attempted write.

Can the hardware path be tested independently?

Use the documented control mechanism for your unit to request a supported visible state from the same machine that runs the bridge. Avoid assuming a network webhook can directly reach a locally connected device without that bridge.

Compare the direct test with the integration's attempted command and connection context. The Status Light listing identifies the desk hardware; webhook receipt, application processing and successful device control are separate facts to verify when tracing an unchanged signal.