Operate the automation

Log and notify without leaking

Record start, result, duration, and actionable errors while keeping file contents, credentials, and private paths out of notifications.

10 minute lesson

~~~

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

Logs should identify the automation, run, input category, result, and duration. That is 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, where it gets 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 with restrictive permissions works too — that is what StandardOutPath and StandardErrorPath already give a LaunchAgent. Either way, write errors to standard error so launchd can keep them separate from routine output. When something breaks, you read the small error file, not a thousand lines of success.

Now the leaking part. Do not paste tokens, clipboard content, document text, or full private paths into logs. The unified log is readable by other tools and admins, log files get zipped into support bundles, and clipboard content might be whatever a password manager copied last. Log files=3, not three filenames with a client’s name in them. Retain enough evidence to diagnose the boundary, not the user’s data.

Notifications follow a stricter rule than logs: send a notification only when the user can act on 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, and the day it fails you will dismiss that too. Notify on the failure that needs a decision. Log the successes.

The realistic failure mode is debugging pressure. Something breaks, you add set -x or start echoing variables, and a token lands in the error log permanently. Add that detail temporarily, behind the dry-run flag, and strip it before the job goes back on the schedule.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →