The Alerts That Won't Stay Fixed: Ranking Recurring Problems Across a Fleet

Every fleet has them: the alert that keeps coming back. You resolve it, feel good for a day, and then the same check on the same machine fires again. And again next week. The ticket gets closed each time — the number in your backlog looks fine — but the underlying problem was never actually fixed. Someone just keeps re-closing a symptom.

These chronic offenders are invisible to a point-in-time view. Your open-backlog dashboard shows one alert. Your trend chart shows healthy inflow and outflow. Your responsiveness metrics might even look great — you resolve it fast every time! None of them tell you that this exact (machine, alert-type) pairing has now fired eleven times this month.

The single-machine WinSentinel agent is free and gives you a full local audit, real-time monitor, scheduled scans and PDF reports. Once you run dozens of those agents, WinSentinel Pro adds the fleet control plane — and the new alerts recurrence command answers a question a standalone tool never can: across every machine and every check, which problems keep coming back?

Recurrence is a different question than volume

It is worth being precise about how this differs from the fleet analytics you already have, because each answers a genuinely different operational question:

• alerts noisiest — volume: which sources generate the most weighted alert load right now.
• alerts aging — backlog age: how long the open pile has been sitting unresolved.
• alerts trends — flow: is the backlog growing or shrinking over a window.
• alerts responsiveness — speed: MTTA/MTTR, how fast you acknowledge and resolve.
• alerts recurrence — persistence: which exact pairings keep re-firing, resolved-then-back, over time.

A pairing can score perfectly on every other view and still be a disaster on this one. Fast MTTR on a check that re-fires weekly is not a win — it is a treadmill.

Group by (node, type), count the comebacks

The command pulls the whole alert stream over a trailing window — open and resolved, so the full lifecycle is visible — and groups it by machine and alert type. Any pairing that fired at least --min-occurrences times (default 2) is a chronic offender. It ranks them by occurrence count, worst first, breaking ties by the worst severity ever seen on that pairing.

winsentinel-fleet alerts recurrence --window 30

Recurring alerts (last 30d, ≥2×)
———————————————————————————
  4 chronic pairings of 37 seen  ·  worst LAB-07/defender_tamper (9×)

  LAB-07    defender_tamper    9×  2 open        [3C 4H 2M]  over 27d
  KIOSK-2   firewall_drift     6×  all resolved  [6M]        over 24d
  BUILD-01  service_recovery   4×  1 open        [2H 2M]     over 19d
  APP-03    time_service       3×  all resolved  [3L]        over 12d

Read the top line: LAB-07 has had Defender tamper-protection alerts fire nine times in a month, two still open, spanning 27 days — including three criticals. That is not a monitoring problem; that is a machine where something (or someone) keeps disabling tamper protection. No amount of fast re-closing fixes that. It needs a root cause.

Each row carries what you need to triage the comeback: how many occurrences are still open versus resolved, the full severity mix, and the span from first to last sighting — so you can tell a burst (nine hits in one bad afternoon) from a true chronic drip (nine hits spread evenly across the month).

Gate on it, and export it as evidence

Like every Pro fleet report, alerts recurrence speaks --json for automation and --csv for an audit-evidence export that round-trips into a spreadsheet, ticket or SIEM — one ranked row per chronic pairing, with first/last-seen as both epoch and ISO timestamps. The command also exits non-zero whenever any pairing is recurring, so a nightly cron can fail the moment a “fixed” problem comes back — the same gate convention as alerts triage and nodes at-risk --needs-attention.

Tune it to your fleet: widen --window to catch slow recurrences, raise --min-occurrences to focus only on the most stubborn offenders, and filter by --severity, --type or --node to scope an investigation.

The workflow that falls out of it: run it weekly, take the top recurring pairing, and instead of closing the next occurrence, ask why it keeps happening. Fix the cause once and it drops off the list for good. That is the difference between resolving alerts and eliminating them.

Free where it should be, Pro where it scales

To be clear about the line: auditing, monitoring and fixing a single machine is free forever — the standalone agent is genuinely best-in-class on its own. The moment you have many machines and need to reason across them — fleet posture, drift alerts, compliance rollups, and now recurring-problem ranking — that cross-node control plane is Pro. You install the same free agent everywhere; Pro turns them into a managed fleet.