What do you do while a build is running?

Set up notifications for the outcomes that actually need action, especially failures or approvals. Then you can move on without keeping the build window in view. If a particular job is genuinely time-sensitive, make that clear in the notification rather than treating every build as an emergency.

Use the wait for nearby work that is easy to pause: review a small change, tidy up a runbook, answer messages, or inspect recent logs. I would avoid starting a task that needs a long stretch of concentration if the build could interrupt you, but there’s no reason every wait has to be idle.

If you need to watch a build because you don’t know what might happen next, that may point to a workflow problem. Automate the normal path, capture useful logs, and send a clear alert when something fails or needs a human decision. The aim is not to eliminate every failure, but to make routine runs safe to leave alone.

For debugging, shorten the feedback loop if you can. Run the smallest relevant check locally or use a workflow mode that skips unrelated stages, then use the full pipeline to confirm the final change. That can turn repeated long waits into quicker tests, though it won’t replace a complete run when one is needed.

Sometimes there isn’t a clever trick. Builds can be part of the work, and failures may need investigation. But if you’re spending most of the day staring at routine runs, focus on better alerts and automation rather than making constant monitoring the job.