The Failure Mode You Traded For
Forgetting to do something is a bad outcome with a built-in alarm. You notice the gap eventually, because the thing you forgot keeps nagging at you in some form, the unpaid bill, the unwatered plant. Automating the task away removes the nag along with the forgetting. That's the trade nobody prices correctly.
Manual memory degrades gracefully. You remember most things most of the time, and when you don't, the absence of the thing is itself a signal. A missed step shows up as a visible hole: the plant wilts, the bill gets a late notice, your own unease about "didn't I mean to do something" pokes at you until you check. The failure is annoying, but it announces itself and it's bounded. You catch it on the next pass.
Automation doesn't degrade. It runs. A cron job that checks disk usage against a path, a certificate renewal, a watcher that restarts a service, all of these execute exactly as well the day before they're wrong as the day after. The code doesn't get fuzzier near the edges the way a half-remembered errand does. It just keeps executing against an assumption that quietly stopped being true, and the output is indistinguishable from success until something downstream breaks loud enough for someone to go looking.
Take a cleanup job that deletes files older than thirty days from a log directory, built on the assumption that the directory lives on a particular mount. The day that mount changes and the script finds an empty folder sitting at the same path, nothing errors. The job runs, exits clean, logs "cleaned 0 files," which reads exactly like a quiet night instead of a broken premise. Compare that to someone who clears logs by hand once a week. If they forget, the disk fills a little, somebody notices, it gets cleared. The automated version replaces a regular small cost with an invisible zero cost that compounds for months into one large cost nobody budgeted for, because the line item said "automated" and automated things don't ask to be checked on.
The usual rule of thumb is frequency: if I do this often enough, it's worth automating. That rule answers the wrong question. Frequency tells you how much labor you'd save. It says nothing about what happens on the day the automation's premise stops holding. A thing you do three times a day and occasionally skip is annoying. A script that does it three times a day until the file it watches gets renamed, and then does nothing forever while reporting success, is a different category of problem, and frequency never flags the difference.
The question that actually matters is what breakage looks like from outside the system, not how often the system runs. If breakage is loud, the deploy fails, the build goes red, the process refuses to start, then automating is close to a straight upgrade. You've traded an easy-to-forget chore for a hard-to-ignore one, and that's a fine trade. If breakage is quiet, a check that passes when it should fail, a sync that silently stops syncing, a renewal that silently stops renewing, you've traded a recoverable annoyance for a debt that accrues in the dark until someone who isn't you discovers it, at a cost that has nothing to do with how many times the job ran correctly before that.
Automate the chore. Just make sure its failure can still get your attention.