Log and notify without leaking

A scheduled automation runs with nobody watching. Logs are how you find out next week whether it worked. Logs are also where automations leak private data. The goal is recording enough, and no more.

One line per run

A log line should identify the automation, the run, the input category, the result, and the duration. One short structured line. Not a transcript:

logger -t screenshot-sorter "run=20260803T1715 files=3 skipped=1 status=ok duration=2s"

logger writes a small event into the macOS unified log, the system-wide log store. You get timestamps and retention for free. Verify it landed:

log show --predicate 'eventMessage CONTAINS "screenshot-sorter"' --last 15m

For higher-volume output, a dedicated file under ~/Library/Logs works too. That’s what StandardOutPath and StandardErrorPath already give a LaunchAgent.

Either way, write errors to stderr so launchd keeps them in the separate file. When something breaks, you read the small error file. Not a thousand lines of success.

What not to log

Tokens. Clipboard content. Document text. Full private paths.

The unified log is readable by other tools and by admins. Log files get zipped into support bundles. Clipboard content might be whatever your password manager copied last.

So log files=3, not three filenames with a client’s name in them. Keep enough evidence to diagnose where it broke. Not the user’s data.

Notify only when someone can act

Notifications follow a stricter rule than logs. Send one only when the user can do something about it:

osascript -e 'display notification "3 screenshots need review" with title "Screenshot sorter"'

A “run succeeded” banner every fifteen minutes trains you to dismiss the automation. The day it fails, you dismiss that too.

Notify on the failure that needs a decision. Log the successes. I’ve never regretted a quiet automation. I’ve regretted noisy ones many times.

The debugging trap

Something breaks. You add set -x, or start echoing variables. A token lands in the error log, permanently.

This is how most leaks happen. Not by design, by debugging pressure.

Add that detail temporarily, behind the dry-run flag from module one. Strip it before the job goes back on the schedule. If you need more detail permanently, log the shape of the data, like its length or its type, never its contents.

Try this: add one logger line to the end of your sort script, run it, and find the line with log show. Then read your error log and make sure no filename in it would embarrass you in a bug report.