From here the tools leave your hands. Before covering how, this page covers what — because the big cost of automation is not the afternoon you spend building it, it is every month you spend keeping it alive.
In this pagetests, worked counter-examples, a ramp. Not in this pagewhat I automate, where it runs, on what schedule.
| Usually omitted | What it is |
|---|---|
| Maintenance | Dependencies drift, APIs change, keys expire. Each automation is a small system you now own |
| Attention | Every notification spends attention — even the ones that say everything is fine |
| Silent failure | The expensive one. It broke and told nobody, and you think it is running. See page 22 |
| # | Test | Failing it means |
|---|---|---|
| 1 | You have done it by hand at least three times | You do not yet know the stable version of the process. You would be automating a moving target |
| 2 | It has an objective success signal | No test means you cannot tell when it is wrong — worse than not automating |
| 3 | You can absorb it being wrong | Irreversible work (deleting, sending, moving money) should not run unattended without a human gate |
"Have it summarise things for me daily" sounds lovely. The question is: who judges whether the summary is good? Without a test, all you get is a stream of output nobody reads and nobody checks. Soon you skip it; soon after, you forget it is still running.
Conversely, "run the tests daily and tell me when they fail" has a perfectly sharp test. That is the sweet spot.
| Kind | Looks like | Why it fails |
|---|---|---|
| The daily nobody reads | A summary generated and sent to yourself every day | High frequency, low per-run value, no success test |
| "All clear" pings | An hourly heartbeat message | Normal is the default state. Reporting normal trains you to ignore it — including the one that matters |
| Automating a one-off | Building a system to run something once | Frequency of one zeroes the benefit side |
| Automating a process you have not settled | Building and redefining at once | Fails test 1. You are fortifying a moving target |
What they share is output with no recipient. The fastest way to judge an automation: who does something different because of its output? No answer, no build.
| Kind | Why it works |
|---|---|
| Checks with a sharp test | Tests, builds, reachability, cert expiry — speaking only on failure |
| Repetitive fixed-step shuffling | Test 1 satisfied by definition; benefit scales with frequency |
| Fixed-time work while you are away | The only category with no manual substitute — and the reason for going to the cloud |
| Step | Do | You are testing |
|---|---|---|
| 1 | Run it by hand, but as a fixed script or a fixed prompt | Has the process actually stabilised |
| 2 | Run on a schedule, output only, no action (dry run) | Is its judgement right — give this at least a week |
| 3 | Let it act, confirming with you each time | Do the actions have side effects you missed |
| 4 | Unattended, speaking only on exceptions | — |
Its only purpose is to show you what it would have done. In that week you will usually find two or three edge cases you never considered — those are exactly what you would have hit had you skipped the step.