RT Robert Truesdale

August 21, 2026

How to Decide If a Task Is Worth Automating

You’re drowning in repeatable work. Another backup check. Another log rotation. Another monthly report. You hear “just automate it” and feel a flicker of hope—then see the task list piling up while your first script sits unfinished in a ~/scratch folder.

Automation isn’t magic. It’s labor. And like any labor, it has upfront cost, ongoing maintenance, and hidden failure modes. If you automate the wrong thing, you trade immediate drudgery for long-term technical debt.

Here’s how to decide, step by step, without the guru nonsense.

1. Measure the Time, Not the Annoyance

“Every day, I spend 20 minutes doing X” sounds small—until you realize that’s 83 hours/year. Or 166 hours, if you factor in context-switching time, interruptions, and the mental tax of remembering to do it.

But don’t just count minutes. Ask:

  • Is the time consistent? If it varies wildly (e.g., “debugging production incidents”), automation won’t help—you need better observability or runbooks first.
  • Is it repetitive and predictable? If the inputs change too much (e.g., “reviewing logs for novel attack patterns”), automation adds fragility without payoff.
  • What’s the real cost? If a mistake costs more than the time saved, automation might be dangerous. (See: “failure modes” below.)

Real example: I automated a monthly billing export for a client. It took 12 minutes manually—copy-paste from three systems, format in Excel, email. Easy. But the export had to be signed off by two people, and one person only reviewed it on Fridays. So I added a Slack notification and a timestamped file archive. Total automation time: 6 hours. Savings: ~10 minutes/week. Net gain: 26 hours/year, after accounting for one bug fix (more on that later). Worth it.

2. The 5x Rule: How Many Times Must You Run It?

A rule I use: Automate only if you’ll run the task ≥5 times in the next 12 months.

Why 5x? Because:

  • Your first automation will break at least once (usually in production).
  • You’ll need to retrain someone or document it.
  • You’ll refactor it once or twice for clarity.

If you’ll do it 4 times, you’re better off writing a quick checklist or alias.

Real example: A team I worked with kept manually updating a CI/CD pipeline’s Docker base image tag. They did it ~3x/year—every quarter, when the base image hit EOL. We debated automating it. But:

  • The change required manual security review.
  • The tag changed only after a vendor release note.
  • If we automated it, we’d get notified before the tag changed, then wait days for review anyway.

So we added a calendar reminder and a checklist item in the release tracker. Saved 15 minutes every quarter. Automation would’ve added complexity for marginal gain.

3. What Breaks? (The Maintenance Tax)

Automation doesn’t run forever. It rots.

Every automation you ship adds:

  • Fragility points: New dependencies (Python packages, API keys, config files)
  • Observability debt: You now need to monitor the monitor
  • Context drift: “This script worked in 2026—what changed?”
  • The “who knows this?” problem: If only you understand it, it’s a single point of failure.

Real example: I built a script to auto-rotate SSH keys for staging servers. Used ssh-keygen, stored keys in Vault, updated config. Worked great—until Vault rotated its own API token every 24 hours. My script broke silently (no alerting on key rotation failure), and two servers lost SSH access for 12 hours.

Fixes:

  • Added explicit health check: ssh -o BatchMode=yes user@host echo "ok"
  • Added monthly “test this” checklist item in our runbook
  • Switched to a Vault token with 7-day TTL, not 24h

The point: Automating the task is only 30% of the work. The other 70% is keeping it alive.

4. Is It the Right Level of Automation?

Not all automation is equal. Pick your level based on risk and scale:

| Level | When to Use | Example | |——-|————-|———| | Shell alias | One-off, personal, low-risk | alias fixperms='chmod -R o-rwx && find . -type d -exec chmod 755 {} \;' | | Script (Python/Bash) | Repeated, predictable tasks with minimal state | Log rotation, config diffing, backup verification | | Orchestrated workflow | Multi-step, cross-system tasks | CI/CD pipeline, incident response playbook | | AI-assisted | Pattern recognition after data is clean | “Flag logs matching known failure signatures” (not “AI fixes it”) |

Real example: A content site I ran had to manually resize images before upload. I tried an AI tool that “optimized” them. It failed on 12% of uploads (corrupted thumbnails, wrong aspect ratio). Switched to a simple ffmpeg script:

ffmpeg -i "$1" -vf "scale=1200:1200:force_original_aspect_ratio=decrease,pad=1200:1200:(ow-iw)/2:(oh-ih)/2" "$2"

No AI. No cloud service. Runs in <2 seconds. Works 100% of the time.

5. The “Why Not Just Do It Manually?” Test

Ask this out loud before writing a line of code:

> “If I had to do this once, right now, with no tools, how would I do it?”

If the answer involves more than 3 steps, you’re automating something that deserves a tool. If the answer is “I’d open a terminal and run one command,” maybe you just need a better alias or shortcut.

But here’s the real test:

  • If the manual version is error-prone (you double-check everything), automate.
  • If the manual version is boring but reliable (you zone out and it works), automate.
  • If the manual version is enjoyable (you like the craft), don’t automate—delegate or eliminate.

Real example: I used to love tuning MySQL queries. I’d dig into EXPLAIN plans, adjust indexes, benchmark. Fun! But it only happened 2x/year. I automated one part: a script that compares slow-query logs between environments and highlights new patterns. Now I only touch the new patterns—not the whole log. Automation preserved the enjoyable part, removed the drudgery.

What I Would Do First

You don’t need to audit every task tomorrow. Start small:

  • Pick one task you did this week. Not the one you wish you automated—the one you actually ran.
  • Time it for three runs. Include context switching (e.g., “I open Slack, then terminal, then run command, then email result”).
  • Ask: “What breaks if I forget to do it?” If the answer is “nothing serious,” it’s low priority. If it’s “production goes dark,” automate it with alerts.
  • Write the simplest thing that works:
  • For local scripts: use bash or zsh, keep dependencies minimal (~/.local/bin), version with git tags.
  • For shared tools: put it in scripts/ at repo root, add a README.md with “When to run this” and “What to do if it breaks” sections.
  • Schedule maintenance: Add a quarterly “check this automation works” item to your personal or team runbook.

Remember: The goal isn’t to automate everything. It’s to automate enough so you can focus on the work that matters—building, debugging, and learning.

If your automation adds more work than it saves, kill it. No shame. I’ve deleted dozens of scripts. Some broke too often. Some were replaced by better tooling (like moving from custom scripts to Terraform). Some just weren’t needed anymore.

That’s not failure. That’s maintenance.

Go fix one thing. Then go get coffee.