Most automation advice is written by people who've never maintained a script in production. They see a repetitive task and immediately shout "automate it!" like it's that simple. It's not.
I've been automating IT workflows for twenty years, and I've learned that automation is a commitment. It needs debugging when it breaks at 2am. It needs updating when upstream APIs change. It needs documentation so the next person knows why it exists. Before you automate anything, you need to ask whether that maintenance burden is worth the time you'll save.
Here's how I think about it.
The Frequency Test Is Overrated
Everyone says "automate things you do frequently." That's not bad advice, but it's incomplete. Frequency matters less than you think. I run ad-hoc queries on our production databases maybe twice a month, but I still do them manually because the context-switching cost of writing a script isn't worth it for something I do irregularly.
What actually matters is:
- Time saved per occurrence — If a task takes 5 minutes and you do it daily, that's 25 minutes a week. Worth automating? Maybe. If it takes 30 seconds, probably not.
- Cognitive load — Some tasks are quick but mentally taxing. Manually checking 50 server logs for errors takes 15 minutes and leaves you drained. Automating it to a single dashboard view might be worth it even if it only runs weekly.
- Error consequence — Manually running a deployment script that could wipe production is worth automating even if you do it quarterly. The risk of fat-fingering something is the real cost.
Don't automate frequency. Automate burden.
The Maintenance Reality Check
Here's what automation guides don't tell you: every script becomes legacy the moment you write it. That clever Python wrapper you threw together this afternoon will need maintenance. The API it calls will change. The authentication will expire. The output format will shift.
I've seen teams spend three weeks automating a process that took ten minutes manually, only to spend the next six months fixing the automation. That's not efficiency. That's ego-driven engineering.
Before you automate, ask:
- Who maintains this when I'm on vacation? If the answer is "I don't know," you need better documentation or a simpler solution.
- How long will it take to fix when it breaks? Some automations are fragile by nature. If your script depends on three external APIs, assume it'll break at some point. Can you debug it quickly?
- Will the input format stay stable? Automating anything that processes human-generated input (CSVs from vendors, ticket descriptions, config files) is risky. Humans change formats without warning.
If you're automating something unstable, you're trading manual work for debugging work. That's not always a win.
Real Examples from the Trenches
What worked: Log aggregation. We had a team manually logging into 12 different servers to check disk space. That's 12 logins, 12 commands, 12 copy-pastes into a ticket. We automated it with a simple cron job pushing metrics to a central dashboard. Took maybe four hours to set up. It's been running for three years with minor tweaks. This was a clear win.
What didn't work: Automated report generation. I built a script to generate weekly status reports from our monitoring systems. It pulled data from four different sources, formatted it into a clean HTML email, and sent it out. Beautiful, right? It lasted about two months. Every week, one of the data sources changed its output format. I spent more time fixing the script than I would have spent just copy-pasting the data manually. Killed it. Never looked back.
The gray area: Content site automation. I run a few niche sites as a side project. I experimented with AI-generated content—titles, outlines, first drafts. The reality: it saved maybe 30% of the time on initial writing, but the editing and fact-checking took longer than expected. For low-stakes content, it was fine. For anything I'd put my name on, manual writing was faster in the end. The automation wasn't worthless, but it wasn't the miracle the hype suggested either.
The Complexity Threshold
There's a point where automation becomes more complex than the task itself. If you're writing a script that's more than 200 lines, has multiple dependencies, or requires explaining for more than five minutes—stop. You're building software, not solving a problem.
Simple automation is:
- Cron jobs that run a single command
- Bash scripts under 50 lines that do one thing
- Macros in your monitoring tool
- Templates that fill in the blanks
Complex automation is:
- Anything requiring its own authentication handling
- Workflows with conditional logic across multiple systems
- Anything you'd need a runbook to explain
If your automation needs a runbook, you haven't simplified anything. You've just moved the complexity.
What I Would Do First
Before you automate anything, do this:
- Time-box the manual process. Actually time yourself doing it three times. Not estimates—real timing. You'll often find it's faster than you thought.
- Try a half-measure first. Can you use a tool that already exists? Most monitoring systems, ticketing platforms, and cloud consoles have built-in automation features. You don't always need custom scripts.
- Write the script, but keep it manual for a month. Run it yourself when you need it, but don't schedule it yet. You'll discover edge cases and breakage points before the automation becomes someone else's problem.
- Automate the boring parts first. If a process has five steps and three are mindless, just automate those. You don't need to automate everything at once.
The best automation is the one you barely notice. It runs in the background, does its job, and doesn't need your attention until something goes wrong. Everything else is just a hobby project dressed up as efficiency.