I handed the weekly patrols to AI — read-only, append to the log, verify before flagging
2026-06-11 / Vol 20 / draft at the time of publishing
In the previous issue I wrote about having 31 URLs in my sitemap while only 1 was actually indexed. I caught that problem only because I happened to open Search Console that day.
"I happened to open it" is a fragile way to run anything. So at the start of June, I set up scheduled AI runs — the AI fires on its own at a fixed day and time — and put three weekly "patrols" into rotation.
Three patrols a week
Here is what's running now:
| Day | Patrol | What it looks at |
|---|---|---|
| Every Friday | PC audit | Configuration checks on my machines (local) + the Microsoft Defender / Intune consoles (cloud) |
| Every Monday | SEO measurement | Search Console — impressions, clicks, and indexing status over time |
| Every Sunday | Site audit | My 3 sites (including this one) — broken links, production liveness, JA/EN parity, accidental secrets in the repo |
None of these checks is hard. What's hard is doing them every single week, and I'm the kind of person who can't. I open Search Console only when I feel like it, and I look at the security console only "when something happens." Looking after something happens is too late — that was the lesson of the previous issue.
I kept the design principles to three
1) Read-only. The patrol never fixes anything. If it finds a broken link or a misconfiguration, it writes it down — that's all. Fixing happens only when I read the log and ask for it.
Not because I distrust the AI, but because if you allow "fix it while you're at it," you can no longer tell what changed when. Patrolling and changing don't belong in the same mechanism.
2) Append to the log. Instead of producing a fresh report each time, every run appends to the end of the same Markdown file. Open that file three months from now and you can read twelve weeks of history top to bottom. The instruction to the AI is also simple: "read the previous entries, then append this week's results."
3) Hand over the known state up front. Deliberate configuration changes — say, a background service I stopped to speed up boot time — go into the AI's memory tagged "this is intentional." Otherwise, every patrol raises the same alert — "a service is disabled!" — week after week, and the log fills up with noise. Defining "normal" in advance turned out to be the single most effective way to cut false positives.
The very first run produced a false alarm
And yet a false alarm got through anyway. Let me be honest about it.
On the very first PC audit, the AI flagged: "an unsigned tool keeps getting blocked from running — consider an exclusion." The report said a security feature was stopping a developer tool I had recently installed.
But I had used that tool just the day before, without any trouble. I pushed back — "that thing should be running fine" — and asked it to dig again. The real story:
・The block was transient, lasting only a few hours right after installation (by-design behavior while a new executable's reputation gets established)
・Indeed, the block records were clustered in a few hours on installation day — and zero ever since
・The AI had read old entries lingering in the console's 30-day report as "still happening now"
Appearing in a report does not mean it's still happening. Humans make this misreading too — and so does the AI.
Afterward I added one line to the patrol rules: before raising a flag, (1) check how recent the records are, and (2) check whether it reproduces on the actual machine. In this case, simply running the tool would have shown "it works" in five seconds.
The lesson: recording "normal" beats detecting "abnormal"
It's been running for less than two weeks, but I've already noticed the value sits somewhere other than where I expected.
Before starting, I thought of this as "a system that finds anomalies early." What's actually paying off is the other thing: a log that accumulates "no change" entries, week after week.
In a log with ten straight weeks of "no change," the week where something does change stands out on its own. Without the records, nobody can answer "wait — since when has it been like this?" Even the false-alarm episode got settled as "transient, long resolved" only because the timestamps were sitting in the log. Recording normal is the groundwork for the day something abnormal happens.
My job: skim the log once a month
So what do I do? Once a month, I skim the log. That's it.
I don't read every line. I skip the stretches of "no change" and pick out only the lines marked "action needed" or "watch," plus the lines whose wording shifted from the week before. If a line catches my eye, that's when I ask the AI to "dig into this one." Deciding whether to fix it — and asking for the fix — happens then, too.
Weekly patrols belong to the AI; the monthly judgment belongs to me. Once I separated patrolling from judging, both became sustainable. It turns out the problem was never my lack of discipline — it was a design that asked the same human to patrol and judge at the same time. At least, that's my story and I'm sticking to it.