Nothing ran overnight. Where do I look first?

At the start condition, before anything downstream. Check whether the event genuinely occurred, whether the condition still matches records that changed shape upstream, and whether the platform can run at all while nobody is present. Downstream steps leave evidence when they fail, so a completely empty record points at the beginning.

How do we notice a silent stop?

By watching for the absence rather than for an error, which needs a deliberate arrangement. A scheduled check that expects a run and complains when there was none is the usual answer, since it converts silence into a signal. Nothing in the automation itself can do this, because from its point of view nothing happened.

Why did it fire twice?

Usually because the far system was told nothing came back and tried again, or because a repeated check saw the same record twice after something changed underneath it. Anything that sends, pays or publishes deserves a guard that recognises a repeat, since duplicate starts are ordinary rather than exceptional.

Glossary

Trigger

A trigger is the event that starts an automated job, and because a job that never starts produces no error at all, it is the first thing to examine whenever nothing appears to have happened.

In plain terms

The thing that sets the job off: a form submitted, a file appearing, a certain time on a Tuesday. It matters more than it sounds because of how it fails. A job that runs badly leaves a mess you notice, and a job that never starts leaves nothing at all, which is much harder to spot and much easier to leave broken for weeks.

Why it matters

Because the characteristic failure here is silence, and silence is what monitoring is worst at. Everything downstream produces evidence when it goes wrong, while a start condition that stops matching produces no run, no error and no record, so the absence has to be noticed by somebody expecting output rather than reported by anything.

How it works

There are broadly three shapes, and they fail differently. Something happens and the far system tells you, something happens and your side asks repeatedly until it notices, or a clock reaches a time. The first is quick and depends on the far end still being configured to call you, the second is slower and more forgiving, and the third is the only one that fires when nothing has happened at all.

The delay between the event and the run is a property of the shape rather than a setting. Being told is close to immediate, while asking repeatedly means an interval during which the event has occurred and nothing has started, and that interval is frequently misread as the automation being broken. Knowing which shape you have explains most complaints about slowness.

Conditions attached to the start are where silent stops originate. A job set to fire on records matching a description keeps working until somebody renames a field, changes a status value or adds a required step upstream, at which point the condition matches nothing, no run occurs and nothing anywhere reports a problem. The automation is not broken in any way a system can see.

Where the automation lives decides whether it can start at all. Anything tied to a browser session depends on that browser being open, while a server-side platform fires on schedule regardless of whose machine is awake. That is a deployment property discovered late by teams who assumed an overnight job would simply run.

Two failures, only one of which announces itself

The reason this failure survives so long in real estates is that it is invisible in exactly the places people look. Somebody checks the run history and finds no failures, which is true. The error alerting has fired nothing, which is also true. The platform's own dashboard is green, because it is reporting on runs and there were none to report on. Every signal available says the automation is healthy, and it is not running. What breaks the deadlock is a check built from the opposite direction: something that knows a run was expected and complains about its absence. That is a small piece of work and it is nobody's obvious job, which is why it is usually built after the first time a silent stop costs a fortnight of missing records rather than before. If an automation matters, the question worth answering on the day it is built is how anybody would find out that it had quietly stopped.

Seen in the wild

A platform whose agents run on events rather than waiting to be asked, with the rules they must follow set when the job is first described.
Lindy
The broadest automation platform, where the event-and-action pairing is the basic unit and the long tail of applications is the durable advantage.
Zapier
A browser-resident tool whose work runs where the browser runs, which is a different starting condition from a platform firing on a server.
Bardeen

Common misconceptions

People assume

If something had gone wrong, we would have been told.

In fact

Only if something ran. A start condition that stops matching produces no execution, no error and no log entry, so the monitoring has nothing to report on. The failure is an absence, and absences are noticed by people expecting output rather than by systems watching for problems.

People assume

It runs the moment the event happens.

In fact

That depends on which shape you have. Being told by the far system is close to immediate; having your side ask repeatedly means a gap between the event and the run that can be several minutes. Most complaints about an automation being slow are actually a description of this interval.

Telling them apart

Trigger vs Webhook

Trigger

The event that starts the job, whatever the mechanism.

Webhook

One mechanism: the far system calling yours.

Every webhook is a trigger and plenty of triggers are not webhooks, since a clock or a repeated check starts just as many jobs.

Questions

Nothing ran overnight. Where do I look first?: At the start condition, before anything downstream. Check whether the event genuinely occurred, whether the condition still matches records that changed shape upstream, and whether the platform can run at all while nobody is present. Downstream steps leave evidence when they fail, so a completely empty record points at the beginning.
How do we notice a silent stop?: By watching for the absence rather than for an error, which needs a deliberate arrangement. A scheduled check that expects a run and complains when there was none is the usual answer, since it converts silence into a signal. Nothing in the automation itself can do this, because from its point of view nothing happened.
Why did it fire twice?: Usually because the far system was told nothing came back and tried again, or because a repeated check saw the same record twice after something changed underneath it. Anything that sends, pays or publishes deserves a guard that recognises a repeat, since duplicate starts are ordinary rather than exceptional.