There is a graveyard of beautifully installed log servers that collected everything and were read by no one. The incident still got discovered late, by a user, on a Friday. The tool was never the problem.
Every guide in this series quietly assumes a person: someone reads the reports, tunes the alerts, notices the silent source. That person, and their routine, is the actual product. EventLog Analyzer just makes their job possible. This page defines the smallest watching routine that keeps the whole system honest, sized for a small IT team that has other work to do.
Saying the IT team owns the logs means nobody does. Pick one named person whose job includes the console, and one backup who covers holidays and sick days. Write both names next to the routine, and make sure the backup has actually logged in and run a search before they are needed.
Ownership includes permission to act: the owner who spots a lockout storm at 9 AM should not need a meeting to start investigating. Agree the first steps in advance and write them on the same page as the routine.
Fifteen minutes is honest for a small network once the system is tuned. The check is shallow by design; its job is spotting, and the deeper work happens in the weekly review or a real investigation.
Once a week, read the five reports from the reports guide in this series properly, tune one noisy alert, and run one verification: cause an event yourself and watch it arrive. This is also when rollout expands, one new source at a time, because the reviewer can see exactly what the addition changed.
Keep a running log of findings and fixes, even one line each. In six months that notebook is your proof the system is alive, and it is the first thing an auditor or a new manager will be glad exists.
Once a month, check the slow variables: disk growth against the retention promise, one archive loaded back and searched, clock offsets spot-checked, licence count against sources actually added. Every one of those has failed silently in real networks, and every one is a five-minute check while it is still cheap.
Send a short monthly summary upward: incidents found, sources added, health of the system. Management that hears from the tool monthly keeps funding it; management that hears nothing assumes it does nothing.
People change jobs, and log systems die quietly in the handover gap more often than from any technical fault. The defence is boring: the routine written down, the backup person real, and the service account and admin passwords stored where the organisation keeps such things, not in the departed owner's memory.
If you inherit a console nobody can explain, treat it as a fresh install: verify sources, clocks, retention and alert routes one by one. This series is, page by page, that checklist.
Install day is in the video. Put the first morning check in your calendar before the trial ends, while the decision is still fresh.
▶️ Watch Full VideoYes, because the routine is sized for exactly that: fifteen minutes daily, half an hour weekly, an hour monthly, split between an owner and a backup. What is not realistic is expecting detection without any of it. Shrink the source list before you shrink the routine.
Parts of it, yes: scheduled reports and alert digests arrive by email, and stale-source checks can be part of that pack. But a human still has to read and judge. Automation delivers the evidence to a person; it does not replace the person.
That is the system working. The routine should name the escalation path in advance: who gets called, what gets preserved, and what the first containment steps are. Deciding that path during an incident is how evidence gets trampled.