Switching it off, on purpose

Nothing is built to be switched off

Every automation is designed, deployed and defended. Almost none is designed to end, so they accumulate: jobs running against processes that no longer exist, reports emailed to distribution lists where half the addresses bounce, a scraper watching a site that was redesigned in 2024 and has quietly returned nothing since.

Retirement is a normal part of the lifecycle and it needs a procedure, or it does not happen.

Review on a schedule, with five questions

Quarterly, for every entry on the register, ask:

1. Is it still running? You will be surprised more than once.
2. Does anybody read the output? Check, do not assume. Open the report and look at who opened it. A weekly digest with no readers for four months is an answer.
3. What did it cost this quarter? Including the maintenance hours, not just the bill.
4. What is its error rate, and who is checking?
5. Would we build this today?

The fifth is the strongest question in the whole review, because it strips out sunk cost. The answer is frequently no: the process changed, a vendor shipped the feature natively, volume collapsed, the team it served was reorganised. A no is a decision to make, not an embarrassment to avoid.

The decommission checklist, in this order

Announce it, with a date, to everyone downstream, including whoever receives the output, whoever depends on the rows it writes, and the on-call rota.

Turn it off, but leave it deployed for two weeks. People notice the absence of something late, and often through a second-order effect: a report that no longer arrives, a field that stopped being filled in. Two weeks of “off but restorable” converts a possible incident into a one-line rollback.

Revoke the credentials before you delete the code. This is the ordering that matters. Once the repository is gone, nobody remembers which service account existed, which API key was issued or which webhook is still registered, and an unused key remains valid indefinitely, attached to nothing, waiting to appear in a breach report years later. Revoke first, then remove the schedule, then delete the code.

Remove the trigger properly. The cron entry, the scheduled task, the webhook registration at the vendor’s end, the queue subscription. A dead consumer leaves a queue growing until it fills a disk somebody else owns.

Export and archive the data, according to the retention policy rather than to sentiment. Keep the decision records for their stated period, delete the payloads on schedule, and note where the archive lives.

Write down what replaced it, or that nothing did and the work went back to being manual. In two years somebody will ask why this is done by hand, and the answer should be findable.

Remove it from the register, with the date and the reason.

The zombie you are preventing

The failure state is a job with no owner, an active credential and a live schedule. It writes into production. Nobody reads its output. Nobody would notice if it started writing nonsense, and eventually it will, because the world it was built for has moved on.

Every element of the checklist above exists to prevent that specific outcome, and the ordering (credentials first) is the part most often got wrong.

Ending well is a good outcome

An automation retired because the process changed is a success. An automation retired because it never delivered what was claimed is also, in its way, a success, for the team that measured honestly and said so rather than defending it for another year.

That is the disposition this whole course has been arguing for. The valuable skill is not building agents. It is looking at a piece of work and choosing the smallest machine that does it, pricing that machine honestly, watching what it actually does in the world, and being willing to turn it off. Everything technical here (the loop, the schemas, the validators, the budgets, the traces) exists to make that judgement possible on evidence rather than on enthusiasm.

The last thing to build is the habit of asking, once a quarter, whether the thing you built should still exist.