Training · Lesson 2

Where To Look When The Automation Is Not Working

The easiest way to know a system broke is when it raises an error. The hard case is the system that runs wrong without one: everything looks fine on screen while the output is quietly wrong. This lesson covers where to look, and in what order, when that happens.

What is a silent fault?

A loud fault announces itself: something stops, a light turns red, a notification arrives. A silent fault announces nothing. The system keeps running, every step reports success, and the result it produces is wrong. It can take days to notice, because nobody suspects something that is working.

The typical shapes are these: a field arrives empty so a calculation runs from zero, a range is written short so a column is never read, a rule is skipped only in one particular case. In all three the system says success. A silent fault is more dangerous.

Diagnosis in three steps

Verify the input first

Is the data entering the system really the data you expect? Field name, range, empty cell. Most faults show up not in the rule but in what reaches the rule. See the input with your own eyes before you read the rule.

Then verify the rule

If the input is right, move to the rule. Write down what it does in which case, one by one, and walk a real example through that writing. A rule that does not hold on paper will not hold in the system.

Count the output last

Compare the number of records you expected with the number produced. If the counts disagree there is a fault, even when nothing shows on screen. Counting is more reliable than looking.

Do not fix what you cannot reproduce

This is the step most often skipped. If the fault does not appear again in your hands, you cannot tell whether the change you made helped. Bring the fault back on purpose once; only then start fixing.

There is another trap. When a checking tool gives the same warning for a long time, that warning stops carrying information. Nobody reads a light that is always red. A warning should be tested now and then to see whether it is still true; otherwise the real fault disappears into the same screen.

If you suspect a system is quietly running wrong, write to us and we can look together.

Frequently Asked Questions

How do I know a system with no errors is broken?
By counting the output. Regularly compare the number of results you expect with the number produced. The gap between those two numbers is the first sign of a fault, even when nothing appears on screen.
Is reading the logs enough?
Often not. A log records what the system did; it does not record what it failed to do. A step that never ran leaves no trace in the log. That is why counting output has to sit alongside reading logs.
I fixed it but I am not sure, what should I do?
Try to bring the fault back on purpose. If it no longer appears the way it did, the fix probably held. If it still appears, the change closed the symptom rather than the cause.
Is changing several things at once a problem?
Usually yes. Make two changes together and you cannot tell which one worked. Changing one thing at a time looks slower during diagnosis but tends to reach the answer faster.
Which tools does this approach apply to?
The tool does not matter. The order of input, rule, output holds in a spreadsheet as much as in an automation flow. Only the name of the screen you look at changes.