How to notice a long Mac build finishing without watching it

Choose a local completion cue for a known build command, keep the build result visible and avoid treating a sound as proof that every check passed.

For a long local build, add one completion cue and leave the log available. That lets you do another small task without repeatedly bringing Terminal forward just to see whether the process ended.

Define what completion means

Inspect the project’s build script. It may compile only, or it may also run type checks and tests. A cue attached to that command represents that script’s end, not checks it never performed.

For a quick success cue, use the afplay pattern. If you need to notice failures too, use separate outcomes and preserve the original exit status.

Keep the review step visible

Leave the terminal window and log intact. When the sound plays, return and check the result, warnings and generated output. Do not start deployment merely because the sound was the successful one.

A build over SSH or in hosted CI does not run its audio through your local Mac automatically. Use the platform’s intended notification channel for those jobs.

Choose useful waiting work

Prefer a short task you can stop when the build ends: read a relevant document, prepare a test case or note the next review step. Starting several unrelated builds can make an anonymous chime hard to interpret.

If an agent owns the build, its turn may continue after compilation. Agent done versus command success explains why the two events should be kept distinct.

Sources: macOS afplay -h; TapNoise cue semantics.

About the author

Rudra Satani makes TapNoise. Spotted a mistake? Email support@tapnoise.com, or reach out at @rudraxx13.

Hear TapNoise on your Mac

Every sound is made by TapNoise itself. Try the sounds on the homepage first, then download the app.