Automation is finished when nobody runs it
Hours saved buy only the first rung of automation. The two that matter are paid for on the failure path, where the person still is.
Good automation takes an operation to zero commands.
An operation run by hand leaves three things on a person. The decisions asked at every step: what comes next, whether this step finished, whether it is safe to move on. The recovery, when the run dies partway: working out where it stopped. And the trigger: somebody had to start it. A script that wraps the steps runs faster and stops at the same points for the same answers.
Good automation takes the three off the person one at a time. One command takes the decisions. A run that is safe to run again takes the reconstruction of where it stopped. A schedule takes the trigger from any operation with no choice left in its input. A business case that counts only successful execution time sees the first of those and stops there.
One command takes the decisions
One command: its inputs are checked before anything moves. The person supplies the choices that must be settled before execution. Every decision during the run belongs to the automation.
An invalid input is rejected before the first change. The same checks and execution rules apply to whoever starts the operation, which is how a standard gets into an operation without anyone enforcing it by hand.
A safe re-run means nobody reconstructs where it stopped
The success path is where the saved hours are. The failure path is where the person still is.
Take an operation that replaces nodes one at a time. For each node, the run creates a replacement, waits for it to come ready, drains the old node, and removes it. Stop it partway. Two versions are now running, and that much is readable. What isn't readable is where the procedure was: whether the drain on that node finished, and whether the old node had already been judged safe to remove. To read the position, you need the model of the operation, which stages finished and which one left a node half built, and the model lives with whoever built it.
An operation whose position only its builder can read has not been handed to anyone, no matter how many people run it. The function is carrying a person where the budget says tool.
The system remembers where it stopped so the operator doesn't have to.
The run records enough progress for the next attempt to distinguish completed work from partial work. Before each stage, it reads that record, so no person has to. Finished work is skipped, partial work resumes where it left off, and nothing gets a second copy. The one thing the run refuses to count as done is a node that still isn't ready after the wait. Nothing was drained onto that node, so the run can remove it and retry creation. When the retries run out, the run halts there, and the next run picks up from that point. What reaches a person is one instruction: fix what it stopped on, and run the same command.
Recovery only counts if someone sees the failure
A job on cron on some host mails whatever it printed to whoever the crontab names and says nothing about whether it worked. A quiet failure sends nothing, and a job that hangs sends nothing either.
Move those scripts onto one scheduler that keeps every run's output and status and sends failures where the team already looks. That changes who can see a failure and who can re-run the job. A hung job doesn't send a failure on its own. It shows on that page as a run that has gone on longer than its earlier runs took, and that overrun is the failure the page sends. The green dashboard is a claim about the host, and the host is fine. The run is what failed.
Jobs go where their failures have an address. The next one lands on the scheduler because its author wants failures to reach the team, and nobody has to decide this is how the team does automation. A page with a button doesn't give a job a safe re-run. A re-run that counts the half-built node as done is a keep-alive with more stages: it reports success because something answered.
A schedule takes the trigger, where no choice is left
Which version to take on, and when, is a risk with an owner outside the run, so an upgrade keeps that choice and stays at one command. For a deploy, merging to the production branch can settle the release decision before the scheduled run begins. An operation that runs rarely and leaves nothing behind when it dies has a recovery cheaper than the checks, and it stays at one command on purpose.
Then the schedule issues the re-run. Take a ninety-day certificate. Renewal is attempted every thirty days, whether the last attempt succeeded or not. The attempt at day thirty fails, the certificate still has sixty days, and the next attempt comes at day sixty with a month in hand. Two misses in a row are a person's job, and the thirty days left are what that person has.
The check is on the certificate the endpoints serve, from outside the run, and someone owns the check. This is where the operator's attention leaves the run and moves to the outcome. The run is invisible, and its failures are not.
The case counts only the successful run
A nightly deploy takes about half an hour by hand, so the first step saved half an hour a night, a real number for a path the person is no longer on. Recovery costs hours too. When the case counts only successful execution time, recovery disappears from the accounting. The number the case counts is the smallest thing the automation buys.
Two acceptance criteria complete the case, and a budget owner already understands both. Who can resume the operation when a run stops, without its builder. For anything scheduled against a deadline, how many attempts it gets before a person has to act, and how many days that person then has. Whoever owns the function decides the operation will run with nobody at the keyboard and pays for the checks on that basis.
Take the newest automation your team has shipped, have someone stop it partway in staging, and see whether anyone besides its builder can recover it with the same command. A decision about where to resume means the operation never left the person, no matter how fast it runs. The same command means the team owns it. Whether it should also run on a schedule is a separate decision.
Nobody having to be there at all is what finished looks like.