A repetitive manual task on your team could clearly be automated. Under what circumstances is leaving it manual the right call, and how would you make that judgement defensible to your team?

## The premise to reject The question contains a trap: that "automatable" implies "should be automated". SRE's own framing sets a *ceiling* on toil rather than a target of zero, and the reasons are practical. Some toil is genuinely cheaper than removing it. Some keeps engineers in contact with production in ways that are useful. And automation is not free — it is code someone owns, tests, debugs at 2am and eventually migrates. A candidate who says "automate it, always" has not yet maintained anyone's automation. ## Test one: does the arithmetic pay back? Do it explicitly, because the intuition is unreliable — tasks that feel intolerable are often cheap in aggregate, and tasks nobody complains about are often the expensive ones. ``` Task A: 10 min, once a week -> ~8.7 h/year saved build 40 h + maintain 5 h/year -> ~11 years to break even Task B: 30 min, every weekday -> ~130 h/year saved build 40 h + maintain 5 h/year -> ~4 months to break even ``` Three inputs people routinely forget: **Maintenance is a real, recurring line.** Automation rots against changing APIs, credentials and environments. Budgeting nothing for upkeep is what turns an automation project into a new source of toil — now you have both the original problem, when the tool breaks, and the tool. **The task's remaining life bounds the whole calculation.** If the system is being decommissioned in a year, only that year's hours are available to recover the build cost. Automating work on a system with a known end date is one of the most common wasted efforts in this area. **Frequency, not annoyance, drives the number.** The task everyone complains about at standup may run monthly. The one nobody mentions may run twenty times a day. ## Test two: is the automation itself a risk? This is the argument that survives even when the hours look favourable. Consider a destructive or irreversible operation performed twice a year — a failover, a bulk deletion, a production data repair. Automating it produces code that is exercised so rarely it is effectively untested every time it runs, and when it goes wrong it goes wrong fast and at full scale. A careful human following a checklist is slower and that slowness is a feature: there are natural moments to notice that something looks wrong. Rarity plus blast radius is the combination that argues for keeping a human in the loop. Note the boundary: this is a reason to *accept* the toil, not a reason to build automation and then hedge it — the safeguards, dry-run and idempotency questions belong to the decision to automate, not to this one. ## Test three: what does this build displace? Engineering time spent here is time not spent on the largest toil source. Teams reliably automate the tractable, satisfying task instead of the messy dominant one, and end up with a pleasing collection of tools and an unchanged toil percentage. If this task is not near the top of the ranked breakdown, the honest answer is often "it stays manual this quarter" — not because it isn't worth automating in the abstract, but because something else is worth more. ## Test four: can the judgement even be encoded? Some tasks are repetitive in shape but require a human decision in the middle — which of these anomalous records is the real one, whether this customer's request is legitimate. Partial automation that handles the mechanical steps and stops for the judgement is often the right shape, and pretending the judgement can be encoded produces automation people override so often it adds work. ## When the arithmetic says no and you automate anyway Be ready for the inverse, because it is the strongest follow-up. Time saved is not the only benefit: - **Error reduction.** A manual step with a history of costly mistakes is worth automating on risk grounds even at negative time ROI. - **Latency.** If a manual step delays every deploy by an hour of waiting, the cost is delivery speed, not engineer hours. - **Interrupt elimination.** Removing an interrupt is worth more than the minutes it takes, because context-switch cost lands on someone doing something else. - **Access and audit.** Automation that lets a non-privileged person self-serve can remove a bottleneck and produce a clean audit trail at the same time. - **Scaling.** If the task's frequency tracks estate growth, today's arithmetic is the most favourable it will ever look. ## Making it defensible Write the estimate down: annual hours, build cost, maintenance cost, expected remaining life, and any non-time benefit you are claiming. Put it next to the same numbers for the team's other candidates and let the ranking make the argument. A decision to accept toil that is recorded with its reasoning is a decision; the same decision made silently is just neglect, and it will be re-litigated at every retrospective until someone writes it down.