Write down what normal looks like first

Before you can catch an automation acting up, you need to know what it looks like when it behaves. Write a short, plain description of a typical run — how long it takes, roughly how much it processes, what the output should look like.

This matters because most failures do not announce themselves. An automation that usually handles a full inbox but only touches a couple of messages one morning is not broken in an obvious way — it just quietly did less work. Without a baseline written down, that kind of shrinkage is invisible. With one, it stands out immediately, because you have something to compare it against. I keep this baseline as a single note pinned next to the automation itself, not buried in a doc nobody ever opens again.

Keep the description short. A few sentences pinned near the automation itself is plenty — this is not meant to be a formal document.

Try this today: write three sentences describing what a normal run of your busiest automation looks like, so you have something to check it against later.