A Notification Light for When Your Build Finishes

The Status Light ($45) is a matte black desk unit with three domed lenses, red at the top, amber in the middle, green at the bottom. It can tell you from across the room that your build has finished. Here is the part most pages leave out: it does not know that your build finished. It has no connection to your compiler, your test runner or your coding agent, and it never will. It changes colour because a command you wired into the end of your build told it to. That wiring is the actual subject of this page.

What does the light know on its own?

Nothing. It is three lamps you can switch on and off from your machine over USB, plus whatever the supplied utility gives you to do the switching. There is no plugin, no integration, and nothing watching your terminal. Everything clever a status light does happens in a few lines of glue that you write once. If you are not willing to write them, do not buy it. We would rather lose the sale here than have you find that out on day one.

Where does the command actually go?

At the end of the thing that finishes. Most people start with a shell wrapper: set the light to red, run the build, then set it green or red again depending on the exit code. It is two lines around a command you already type, it works with every build tool that exists, and it asks nothing of the tool itself.

If your build runs through a task runner or a makefile, the same two calls can live there instead, as the first and last steps of the target. If an agent runs the build for you, look for whether your tool can run a command of your choosing when a run starts and stops. Claude Code will run a command you nominate at defined points. Other tools have their own equivalent, or none at all. Where there is none, wrap it.

Which colour should mean what?

Our suggestion is red while it is running, amber when something is waiting on your input, green when it is finished, which reads straight down the unit in the order the lenses sit. Map them however you like. The only rule worth keeping is that you decide once and then leave it alone, because the whole value of an ambient signal is that you stop reading it and start simply knowing.

Add a reset. The first time a build dies badly the lamp stays red, and from then on you will quietly distrust it. One line at the start of a shell session fixes that permanently.

What about failures, and builds that run somewhere else?

Failure is the case worth getting right, because a red lamp meaning running and a red lamp meaning broken are the same lamp. Give failure its own behaviour, flashing rather than steady, or let red mean failed only once the run is over. Exit codes make this easy: your wrapper already has the number in hand.

Builds on a remote machine or a shared runner are harder, because the moment you care about happens somewhere your desk cannot see. The honest options are to have the remote job touch something your machine watches, or to accept that the light covers local work only. We have not built a hosted service for this and will not pretend we have.

Is this better than a desktop notification?

Different, not better. A notification is precise and interrupting: it names the thing and lands on top of whatever you were reading. A light is vague and passive: it holds one fact in your peripheral vision until you happen to look up. If you already ignore notifications because there are too many of them, the light helps. If you miss builds because you walk away from the desk entirely, neither one helps and a sound is the better answer.

If you want the wiring options laid out side by side, we went through them in how to show agent state outside the terminal.