Test Your Automation on the Day You Rest

Most people grade their automation on a busy day. The question is how much time it saved when everything landed at once.

Last Sunday I took the whole day off, and the grading changed. A post I had scheduled went out in the evening exactly as planned, and the video and image jobs I had queued overnight were finished by morning, untouched. I had done nothing.

The quality of an automation shows on the day you rest, not the day you are busy.

A quiet afternoon desk by a window, laptop left open, nobody in the room

Why busy-day grading flatters you

On a busy day you are there. An automation that only half works still looks fine, because you fill the gaps without noticing: no alert arrives so you check manually, something stalls so you restart it, output appears in the end. It gets recorded as "running well."

Anything that needs a person standing next to it is not automation, it is semi-automation — and on a busy day the two are indistinguishable. They separate only on a day nobody is watching.

Three things to check after a day off

Spend a day without touching anything, then the next morning look at exactly three things.

1. Did output actually appear? Check at the scheduled hour for a finished artifact, not a log line. "Job started" tells you nothing. A run that executed flawlessly and produced nothing publishable is a failed run.

2. If something failed, did you find out? This one matters more. Failures happen; the real problem is going two days without knowing. If a job failed on your day off and nothing reached you, that automation only works when it succeeds.

3. Is there cleanup waiting for you? This is the one that catches most setups. The output exists, but filenames need fixing, something ran twice and one copy must be deleted, or it takes half an hour just to work out where things stopped. That is not rest — it is rest borrowed against tomorrow. An automation that generates cleanup has simply moved the work, not removed it.

Each failure points at a different repair: the first at run conditions, the second at alerting, the third at the finishing step.

Rules that make the rest guilt-free

Working alone, days off are rarely restful. The fact that you produced nothing today sits there all evening.

This is where the value of automation actually lives — not in speed. When output keeps arriving on the days you rest, resting stops costing you guilt. The day can be empty and the thing that needed to go out has gone out.

For that to hold, decide how you behave on the day off too.

Check once. Look at the output in the evening, and only the output. The moment you open logs, it stops being a day off.

Fix it tomorrow. If you spot a failure, write one line in a note and leave it. Small repairs eat whole days when you start them on a rest day.

Alert only on what cannot wait. Every alert on and you cannot rest; all of them off and you learn about incidents late. Keep the ones a human must handle that same day.

What has to be in place before this test passes

The rest-day test is close to the final gate. Three things stand in front of it.

Choosing the hour, and deciding whether a missed run catches up — scheduling and missed runs

Knowing that saving is not finishing, and verifying the public result — the four checks

Deciding what to keep and what to switch off — the automations I turned off

With those three standing, most setups pass a rest day. Without them, every rest day snags in the same place.

In short

Busy days hide the truth because you are quietly filling the gaps.

Rest a day, then check output, failure alerts, and leftover cleanup.

Cleanup-generating automation is rest borrowed against tomorrow.

On the day itself: check once, repair the next day.

The point of automating is less about saving minutes and more about output continuing on the days you rest, so that resting costs no guilt.