Which infrastructure automation actually pays back?

What is the actual payback test?

Frequency multiplied by the number of people affected, minus the cost of keeping it working. The last term is the one that gets omitted, and it is usually the largest. Any automation that touches a cloud provider, a CI system or an authentication flow will need attention several times a year because those things change underneath it, and that ongoing cost has to be set against the saving before anything is built.

The rule this produces is unglamorous: automate what is done weekly by several people, not what is done annually by one. A quarterly task that takes an afternoon is a poor candidate even though it feels wasteful, because a script used four times a year will be broken three of those times and nobody will remember how it works.

There is a second term that people leave out in the other direction, which is the cost of the task being done inconsistently. Access provisioning done by hand is not just slow; it is done slightly differently each time, and the divergence is the actual damage. Where consistency is the point, automate below the frequency threshold.

Which tasks reliably return more than they cost?

Ones with high frequency, mechanical resolution and a real cost to getting them wrong. The table sorts the common candidates by whether they earn their maintenance, which is a different ordering from how satisfying they are to build.

Which automation quietly costs more than it saves?

Bespoke internal command line tools with one author, wrappers that reimplement a supported product's interface, and anything that generates code nobody can subsequently edit. All three feel like progress and all three convert a documented public tool into an undocumented private one, with the documentation living in one person's memory.

Automatic remediation deserves particular scepticism. A job that restarts a service when it becomes unhealthy removes the symptom and hides the cause, so the underlying fault continues undetected until it grows past what a restart fixes. If you build one, make it visible and noisy: it should record every intervention somewhere a human reviews weekly, and a rising count should be treated as an escalating fault rather than as the system working.

The general test is whether the automation can be debugged by somebody who did not write it, at three in the morning, with only the repository. Anything that fails that test is a liability held by whoever wrote it, and its value evaporates on the day they leave.

Why does the manual step usually survive?

Because it is an approval or a judgement rather than a task. When people describe a process as manual, the mechanical parts are often already scripted and what remains is somebody deciding that this change is safe to release, or that this person should have this access. Automation projects that treat those as steps to eliminate stall, because the organisation is not trying to remove them.

The productive move is to automate around the decision rather than through it. Assemble everything the decision needs, present it in one place, and reduce the act itself to a single confirmation with a recorded outcome. That removes the twenty minutes of gathering context and keeps the accountability, which is what the step was there for.

This also explains a common false measurement. A team reports that deployment is fully automated, and it is, but a release still takes three days because it waits for a change advisory meeting held on Tuesdays. The automation worked and the lead time did not move, because the constraint was never the mechanical part.

Who maintains it after the person who built it leaves?

This is the question that should be asked at the start and almost never is. Every piece of internal automation is a small product with users, and it needs an owner, a place to raise problems and a decision about what happens when it breaks and the author is unavailable. Without those, it degrades into something people work around while nobody admits it is dead.

The cheapest protection is preferring supported tools over written ones. A managed dependency update service, a standard CI feature or a provider's own capability carries a maintenance burden somebody else pays. Internally written equivalents are justified when the requirement is genuinely specific, and that is a smaller category than engineers building them tend to believe.

Where you do build, make the failure mode obvious. Automation that fails loudly and stops is safer than automation that fails silently and continues, because a stopped job gets fixed while a silently degraded one produces incorrect state that surfaces months later during an unrelated incident.

How do you decide this afternoon?

Export the last month of tickets and interruptions, group them by title, and count. This takes an hour and produces a list that is almost always different from the automation backlog people carry in their heads, because memory over-weights the annoying and under-weights the frequent. Anything appearing more than four times with a mechanical resolution is a genuine candidate.

Then apply two filters to the top of that list. Is the resolution actually mechanical, or does it end in somebody deciding something? And who will own the automation in a year? Items that fail either filter go back to the list, and the ones that pass are usually a short list of two or three, which is the correct size for a first quarter.

For a candidate interview, this makes a good exercise. Give them a genuine month of ticket titles and ask what they would automate first and what they would leave alone. The answers reveal whether someone reasons about maintenance cost or reaches for the most technically interesting item, and that difference predicts a great deal about the following year.