Whose is it, at 3am, in eight months

The state to avoid

Most failed automations are not badly built. They are orphaned. Somebody enthusiastic built a thing that worked, then changed teams. It kept running. Six months later it is still writing into a production system, on a credential nobody can trace, and nobody is reading its output.

Orphaned-but-running is worse than switched off, because it acts without supervision. There is no alert because the person who would have configured one has gone. The first sign that anything is wrong is the consequence.

Three roles, on one page

They may all be the same person. They must all be named.

Owner. Decides whether it keeps running, and is accountable for what it does. Usually the manager of the process, not the engineer: the person who would answer for the outcome if a customer complained.

Maintainer. Fixes it. Knows where the code, the credentials and the prompts live.

On-call. First response when it breaks at an inconvenient hour. May be a rota that knows nothing about this system beyond the runbook, which is exactly why the runbook exists.

If any of the three is “we’ll sort that out later”, the project is not finished.

The handover file

One markdown file, next to the code, containing:

• What it does, in three sentences, and who asked for it.
• What triggers it and how often it runs.
• Which systems it touches and with which account.
• Where the credentials live and when they expire.
• How to stop it: the exact command or the exact button.
• The runbook: the four failures that have actually happened and what to do about each.
• Where the golden task set is and how to run it.
• What it costs a month.
• The date it was last reviewed, and by whom.

That last line is the one that makes the file honest. A handover document with a review date eighteen months old is telling you something true about the system.

The bus factor is tested, not assumed

Somebody who has read the documentation has not demonstrated anything. Once a quarter, have the second person do a real deploy and a real rollback while the first person watches and says nothing.

It takes an hour and it finds the undocumented step every time: the environment variable that is only on one laptop, the manual approval in a console nobody mentioned, the script that must be run from a particular directory. These are always present, and they are only discovered by somebody who does not already know them.

Personal accounts are the classic failure

An automation built on somebody’s personal API key, billed to their card, authenticated with their Google account. It works perfectly until one of three things happens: the card expires, the person leaves and IT deletes the account, or the vendor changes their consumer terms and the data is now being used differently from what the organisation agreed.

All three have happened to plenty of teams and all three are avoidable on day one with an organisational account and a service credential. If a pilot must start on a personal account, put an end date on it in writing, because otherwise the pilot becomes the production system by the ordinary process of nobody stopping it.

An owner who cannot read the output is not an owner

Ownership requires being able to tell whether the thing is doing its job. That means the owner needs a weekly view they can understand without a terminal: how many items were processed, how many failed, how many went to a person, what it cost, and a link to ten recent examples.

Ten examples is the part that works. A manager who reads ten outputs a week develops a feel for the system that no dashboard produces, and they are the person most likely to notice that the tone has drifted or that a category has started appearing that should not. Build that page early; it is the difference between an owner in name and an owner in practice.

Keep a register

A single list, one row per automation: name, what it does, owner, systems touched, credential and its expiry, kill switch, last reviewed, monthly cost.

Ten automations is roughly where an organisation stops being able to enumerate them from memory, and it arrives faster than expected because each one is small. A spreadsheet is fine. What matters is that it exists and that adding to it is part of shipping: an automation that is not on the register does not exist to whoever is on call, and that is precisely the one that will page them.

Review the register quarterly, out loud, with the owners in the room. Half the value is the systems somebody says “oh, that’s gone” about, and the other half is the ones where nobody in the room knows the answer.