Automation Isn’t Finished When It Runs Once.

A green checkmark proves the workflow ran. It does not prove the workflow is sensible, efficient or trustworthy.

I had an automation that worked perfectly.

This was the problem.

It was a small test: check an inbox, find a particular file and move the next bit of work along automatically. Nothing especially exotic. The workflow ran. The connections were healthy. The little green ticks appeared exactly where little green ticks are supposed to appear.

It also checked the inbox every minute.

That is 1,440 checks a day for something that absolutely did not happen 1,440 times a day.

By the time I looked properly, one test had quietly chewed through more than 14,000 Make credits while behaving exactly as instructed.

A successful run is not the same thing as a successful system

Automation demos are wonderfully persuasive because the satisfying bit is visible.

A thing happens. Another thing notices. A third thing updates. Everybody nods.

What the demo does not show is Tuesday three weeks later when a connection expires, a field changes name, a duplicate arrives, the volume doubles or nobody remembers who is supposed to notice that the workflow stopped.

The first successful run proves one thing:

Useful. Not remotely the same as proving it can be trusted.

Frequency is a business decision

Every-minute polling made sense while I was testing because I wanted the result immediately. It made almost no sense in production.

If the event I am waiting for happens a few times a week—or a few times a month—checking 1,440 times a day is not responsiveness. It is anxiety with an API connection.

The sensible frequency depends on the consequence of waiting.

A payment confirmation may need to move quickly. A weekly PDF does not. A website inventory change might justify frequent checking. An administrative digest probably does not.

The question is not, “How often can this run?”

It is, “How quickly does the business actually need to know?”

The invisible parts are the production system

Once an automation matters, I want five answers before I call it finished:

• Owner: Who is responsible for knowing whether it still works?
• Signal: What tells us the automation succeeded, failed or quietly did nothing?
• Cost: What does the schedule consume when there is nothing useful to process?
• Recovery: What happens to the work when the automation fails?
• Evidence: What proves the outcome happened—not just that the scenario ran?

That last distinction matters more than it sounds.

A workflow log can say “success” because it checked an inbox and found nothing. That proves the check worked. It does not prove that a payment reached the right tracker, that a form reached the right owner or that the person waiting for the output received anything.

Green is a technical status. “The right thing happened” is an operational one.

Automation should remove work, not hide it

The easiest automation to build is often the one that moves a task from somewhere visible to somewhere nobody is looking.

The form submits beautifully. The data lands in a sheet. Excellent.

Who checks the sheet?

The email arrives. The attachment is saved. Lovely.

What happens if the attachment is malformed?

The dashboard updates. Terrific.

Who notices when it stops?

This is why I have become much less interested in the question “Can we automate it?” and much more interested in “What work are we actually removing?”

If the answer is “none, but now there are six scenarios to maintain,” we have perhaps misunderstood the assignment.

The boring questions are usually the useful ones

I like AI. I like automation. I like the slightly ridiculous moment when two systems that were never designed to know each other suddenly exchange exactly the right piece of information.

But the interesting part is not the connection.

It is deciding what deserves automation, how often it should run, what “good” looks like, what it costs, who owns it and what happens when reality behaves differently from the test.

That is less cinematic than watching a workflow light up.

It is also the difference between a clever demo and useful infrastructure.

Use AI. Use automation. Own the outcome.

The tool is allowed to be clever. The operating model still has to be sensible.