The halt that could not be cleared
An agent rollout stopped itself over a laptop that was switched off, a reprocess button offered work nothing could run, and the insights feed filed our own test traffic. Four false alarms, fixed.
A monitoring product that cries wolf teaches you to ignore it. Everything in this release is Wegweiser reporting a problem that was not there, and every one of them is now gone.
A rollout that stopped itself over a powered-off laptop
The agent update channel has a circuit breaker, and the trigger that matters most to it is silence rather than failure. A build that kills agents produces no error reports at all, because dead agents report nothing. So the breaker asks a simple question: of the devices an installer has actually run on, how many are still checking in?
It was asking that question with no time limit on the far side. Every device that had ever installed a version stayed in the population for good, judged for ever on whether it happened to be powered on at that moment. On one fleet, three machines had installed the agent cleanly and confirmed it, 30 days, 29 days and a week earlier. Two of them were switched off. The breaker read that as two agents the build had killed, and halted the rollout.
Halts are deliberately sticky. A breaker that resets itself the moment the number drifts back is not a breaker, so clearing one is a human action that gets recorded. But this halt could not be cleared by anyone. The rows it was counting never changed, so clearing the halt simply recomputed the same three machines a minute later and halted again.
The question now has both edges. A device is watched from fifteen minutes after its installer ran, which is long enough not to mistake a service restarting for a service dying, until forty eight hours after it, past which a quiet machine is just a quiet machine. The window is measured against each device's own install, not against the rollout, so a ring that opens over a fortnight still gets the full watch on every box as it lands.
A Windows machine waiting on a reboot is out of that population too. An installer that ends in "reboot required" has succeeded: the payload is in place and the service stays down until someone restarts the box, which is a wait measured in days. That is silence with a known cause, and it was being counted as evidence of a dead agent.
None of this makes the breaker quieter about real trouble. A build that rolls machines back, one that fails to roll back, and one that leaves machines part-installed and silent all still stop the rollout exactly as before.
Reprocess stops offering work it cannot do
"Reprocess analyses" on a device page re-runs what has already been collected. On Linux devices that had ever run a Lynis audit, it offered the audit as one of the items.
Lynis is parsed rather than interpreted, which is why it costs nothing to run. No analyzer consumes it, so selecting it queued a request that nothing would ever pick up. That stranded request then counted as work already in flight, which quietly removed Lynis from every later reprocess of the same device, and the confirmation dialog counted it in the total and priced it at a wegcoin for work that could never happen.
The preview now counts and prices only analyses that will actually run.
The insights feed stops reporting its own tests
Health Insights reads the application logs and files what looks like a genuine fault. Three of the issues it filed were the login form's bot defences working correctly, triggered by our own end to end test suite: a headless browser submitting an address at a reserved domain that can never belong to an account. The form refused a submission typed faster than a human can type, and turned away a password that was wrong. Nothing was authenticated and no data was touched.
Those two messages are no longer filed when they come from an automated client, and deliberately still are when they come from a real browser. Someone locked out of their own account has to reach a person. The real threat underneath, an attacker grinding the login form, was never handled by filing an issue in the first place: every failed attempt feeds the IP blocker, which drops the address and lists it for review.
One more fault was arriving as two reports. A session identifier appears in some log lines, and the step that strips out per-request noise was masking those identifiers inconsistently, depending on where the random characters happened to fall. The same single event could produce two different fingerprints and therefore two separate issues. Identifiers are now masked the same way every time, so one fault is one report, with a count against it.
Where this leaves things
Three of these four had already filed themselves as bugs through Health Insights, which is the feature doing its job on its own product. The fourth was found while checking whether the first fix had actually worked. It had not: the rollout that halted was never in the state the original fix addressed, and it was still halting an hour before this went out.
That is worth saying plainly, because it is the reason the check is part of the work and not an afterthought. A fix that closes an issue without clearing the condition is a false alarm of its own.