Watch, do not improve

For the first week, resist changing anything unless it is actively causing harm. Read what it reports each day. You are gathering evidence about which of your imagined problems are real, and it is usually a different set than you expected.

What to look for

  • How often is the no-op case? If most days there is nothing to do, your reporting should be quiet on those days or you will train yourself to ignore it.
  • What did it skip? Skips are where the interesting edge cases hide.
  • Did it ever run twice? If yes in week one, it will happen constantly. Check the guard held.
  • How long does it take? Note the normal range. A run that suddenly takes four times as long is often the first sign of a problem, and it is only visible if you know the baseline.

The handover note

This is the step that separates a personal script from something a business can rely on, and it takes fifteen minutes. Write down, in the same place as the automation:

  1. What it does — the one-line trigger/outcome sentence from section 1.
  2. Where it runs and how it is triggered.
  3. How to tell it is working — where the heartbeat is, what the watcher is.
  4. How to run it by hand — the exact command or button.
  5. The manual fallback — how a person does this job if the automation is dead and you are unreachable.

Point five is the one people leave out and the one that matters most. An automation without a written manual fallback has not removed work from a person — it has concentrated it into one person, and that person is now a single point of failure with a job.

Then leave it alone

Add features only when a real event demands one. Every line you add is a line that has to keep working through the next three years of upgrades, password rotations and moved files. The best automations I run are small, boring, and have not been edited in a long time.

Last modified: Monday, 17 August 2026, 1:10 PM