> ## Content Index > Fetch the complete content index at: https://mikegarcia.io/llms.txt > Use this file to discover other available public pages before exploring further. # Automation is finished when nobody runs it - URL: https://mikegarcia.io/automation-is-finished-when-nobody-runs-it/ - Published: 2026-09-12T19:00:00.000Z - Updated: 2026-09-20T22:09:56.000Z - Description: A case that counts only successful execution time buys the first step of automation. Whether the team owns the operation is decided on the failure path. - Author: Miguel Garcia - Tags: Automation, Infrastructure, Reliability, Platform Engineering 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 requires reconstructing where it stopped. A schedule takes the trigger from any operation with no choice left in its input. A budget owner who 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 is handled by the automation. An invalid input is rejected before any changes are made. The same checks and execution rules apply to whoever starts the operation, which is how a standard gets into an operation without anyone having to enforce 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 are 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 are exhausted, the run halts, and the next run resumes from that point. What reaches a person is a single instruction: fix where it stopped, then run the same command. The re-run trusts its own record. A stage marked finished whose effect was undone behind it gets skipped as done. ## 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 to a single scheduler that retains every run's output and status and routes failures to 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 taken longer than its earlier runs, and that overrun is the failure the page reports. 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 provide a safe way to re-run a job. 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 when the owner is outside the run, so an upgrade preserves that choice and keeps it to 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 30 days, regardless of whether the last attempt succeeded. The attempt on day thirty fails; the certificate still has sixty days, and the next attempt comes on 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 shifts from the run 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, the person approving it never sees recovery at all. The number the case counts is the smallest thing the automation buys. The half hour also assumes the interruption is free. A nightly run arrives on its own schedule rather than yours, and the cost of stopping what you were doing is paid on the nights it succeeds as well as the nights it doesn't. 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 through staging, and see whether anyone other than 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.