When NOT to Automate

Automation is a tool, not a default

Everything in this module so far has made the case for automation. This lesson is the other half of that judgment: recognizing when a task isn't ready for it yet — not because automation is dangerous, but because it works best on a specific kind of task, and forcing it onto the wrong one causes exactly the kind of mistake automation is supposed to prevent.

The three-question framework

You've already seen pieces of this across the module. Here's the full version, as a decision you can actually walk through:

A "no" at any of these three points isn't a dead end — it's useful information. It tells you what has to change before automation makes sense here: do the task by hand a few more times until the process is clear, or figure out how you'd actually verify the result, before writing anything that touches real devices.

Why "one-off" is a poor starting point

Say a legacy router needs an unusual, one-time configuration change during a planned maintenance window — something that's never been done on this network before, and won't be done again once it's finished. It's tempting to script it anyway, since you're already going to be typing the commands.

But this fails the first question: it's not repetitive. There's no second or third time this exact task runs, so there's no repeated execution for a script to save you from — and writing one adds a layer of code that itself needs to be trusted, for a task that was only ever going to happen once. A careful, well-documented manual change — ideally with someone else reviewing the plan first — is the better fit here, not because scripting it is impossible, but because the payoff isn't there for a task you'll never repeat.

Why "not well understood yet" matters just as much

During an active outage, it's rarely clear right away what's actually wrong. Reaching for an automation script to "fix it" before you know what's broken means the script is guessing at a process nobody has actually confirmed yet — which is precisely how a script turns one problem into two.

This is the second question in the framework: is the process well understood? Automation encodes a procedure someone has already figured out and trusts. During active troubleshooting, that procedure doesn't exist yet — figuring it out is the work. Automation belongs after that investigation, for the parts that turn out to be repeatable, not as a substitute for the investigation itself.

Why "can it be validated" is the quiet dealbreaker

The last question is easy to skip past, but it's often the one that actually matters most: if you can't tell whether the result was correct, automating the task just means failing faster and with less visibility, not failing less.

Picture a script that pushes a config change to 40 switches but has no way to confirm the change actually took effect — no show command to check afterward, no expected value to compare against. If something goes wrong on switch 17, nobody finds out until it causes a problem days later. The task might be repetitive and the process might be well understood, but without a way to validate the outcome, you've automated the risk right along with the task.

This isn't about automation being risky

It's worth closing on this clearly, because it's easy to walk away from a lesson titled "When NOT to Automate" with the wrong takeaway: automation isn't inherently more dangerous than doing something by hand. A rushed, unreviewed manual change during an outage is just as capable of making things worse as a rushed, unreviewed script.

The point of this framework isn't caution for its own sake — it's fit. Automation is extremely good at repetitive, well-understood, verifiable work, and that's exactly why it's worth using there. Reaching for it outside that fit — a one-off task, an unclear process, an unverifiable outcome — is what's risky, not automation itself.

Where this module leaves you

Across this module, you've gone from "what is network automation" to being able to look at a real task and reason about it: is this a good candidate, what would the manual and automated versions look like side by side, which category does it fall into, what would the workflow stages actually be, and — now — is it actually ready to automate at all.

That's the judgment this whole platform is building toward. From here, the next module — Network Automation Fundamentals — builds on that judgment with the concepts underneath how automation actually works: inventory, configuration vs. state, idempotency, and safe failure handling, before this curriculum gets to writing any code.