---
title: "Building ops-cli background After the Third Popup That Week"
canonical: https://dxdev.com/blog/stale-observability-breaks-diagnosis/
datePublished: 2026-08-03
---
The PowerShell window popped up again at 1:48 PM, the third time that week. We went looking for what spawned it and found something worse: nothing on the machine could tell us what was actually running.

## Chasing the window

The first move was the obvious one. Find the process, find the task that launched it, kill the task. We did that for the first two instances, and each time a new window showed up somewhere else. A scheduled task, a stray script, a leftover from a Discord bot restart. Three separate root causes, all rendering the same symptom. We were patching sightings, and we only noticed because the fourth window looked exactly like the first three in the screenshot.

## The README was wrong

The next thing we reached for was the README. We keep one that lists what's supposed to be running on this box: which agents, which scheduled tasks, which bots. We opened it to cross-check against the process list and it didn't hold up. It listed a task by a name that had been renamed two refactors ago. It didn't mention the platform Discord agent at all. It claimed a background watcher was disabled when Task Scheduler showed it running hourly. We had been treating a doc as ground truth for the state of a live machine. The doc doesn't know when someone renamed a task, and the machine does.

## Building `ops-cli background`

So we stopped chasing windows and built `ops-cli background`, a command that derives its answer from the machine. It walks the actual process list, cross-references Task Scheduler entries, and inspects what each one can do. There's no README in the loop to fall out of sync.

The mechanism is simple. Enumerate the scheduled tasks, resolve each one to its actual command line, check whether the referenced script or executable still exists at that path, and flag anything that starts an interactive shell without `-WindowStyle Hidden`. That last check is what found it. Two of the four window-spawning tasks were calling PowerShell with no window flag at all, launched months apart by different fixes to different problems, both missing the same one-line switch.

Once the tool reported what was really running, the fix took minutes. We cleaned up the tasks causing the windows and got the platform Discord agent running hidden. Then we verified with the same tool that it stayed up, because a log line that says "started" and then goes silent proves nothing about the process.

## The same failure, one layer down

The eighteen-hour session that produced this also touched the work we were supposed to be doing, which was giving each developer their own agent. That work stalled twice for the same reason at a different layer. An agent that had been pushed looked done because the deploy log said so, but the process on the machine was still running the old code. The fix was a check that reads what the live process actually started from. It cost about three hours across three machines to notice, because "pushed" and "running" look identical in every log that only records the push.

## A claim is not an observation

Any status that comes from a system telling you about itself is a claim. A README is a claim. A deploy log line is a claim. A task name is a claim. The only observation is asking the machine directly, right now, what's loaded and what it's doing. Once `ops-cli background` existed, the recurring popup stopped being a mystery to solve case by case. It was one line in a table that had been lying to us since before we started looking.

If your team keeps a list of what runs on a server, check it against the server. Read the live process and its scheduled tasks, and after any deploy, check what the running process actually started from, since a successful push only tells you the push worked.