A job crashed for six days with clean logs; only its exit code said so

A home-services owner asked me whether, when they miss a call while on a job, people leave a voicemail or ring the next company. I have no figure for that and won’t pretend to one. What I can speak to is a nearby problem I have measured: the system that was supposed to catch the call, or the message, or the follow-up, looked busy and healthy while it did nothing.

The incident: six days, fourteen lanes, no error in sight

Between 30 Aug and 5 Sep 2026, one of our automation lanes was dead. It ran on schedule and wrote a normal start line. It then listed every profile it was about to visit, which made the log look like a job in full swing. Then it crashed while assembling its own context, before doing any of the work it had just announced.

Anyone reading the log body would have seen a start, a list of planned work and a stack trace at the bottom. The trace was easy to miss under that much activity. The only thing that told the truth was the exit code at the very end.

I did not find it by reading that log. I found it by auditing exit codes across all fourteen lanes at once, and one of them had been returning a failure for six days. Every log I had skimmed in that period read as clean.

The mechanism: a log records that work started, not that it finished

A log is written by the same program whose behaviour you are trying to check. Unless the program is built to report its own failure at the end, it will record what it intended to do. The start line and the list of profiles were true statements about intent. They were not evidence of output.

So the absence of an error message is not evidence of anything. A clean log carries no information about whether the work happened. If the only signal you have is “nothing looked wrong”, you cannot tell a healthy job from one that died early and quietly.

This is the same family as another failure I have documented in our tooling. Our input tool clamps an off-screen coordinate to the edge of the screen. It does not stop and complain. It presses whatever happens to be at the edge. The click lands, the tool reports that it clicked, and the click was on the wrong thing. The dangerous failure is the one that succeeds at something else.

Why a status that can’t be trusted is worse than none

Once I had the exit codes in front of me, a second problem showed up. A signal is only useful if it means one thing.

In one lane, the exit code was the number of messages sent. The caller compared that number to 2, and 2 was also the code for a dead session. A run that delivered exactly two messages reported itself as dead. In the other direction, a dead session could look like a good run, and both cases were suppressed.

That is why I would rather have no signal than a shared one. A success and a failure sharing one number is worse than silence, because it gives you confidence in a reading that cannot be interpreted.

What I would ask any vendor, or my own team

I am not suggesting you read exit codes yourself. If you are buying automation for a small business, you are paying someone to carry this. The questions below test whether they do.

What tells you a job finished, rather than that it started? Ask them to show you the specific signal. “We check the logs” is not an answer, because the log from my dead lane was busy and wrong.

Does a failure get its own signal? A failure should not share a code, a message or a colour with a success. Ask what the system sends when it cannot do the work, and where that goes.

Who counts the failure? I have also seen one browser session die three times over a single weekend, once in each of three different lanes. Each lane counted only its own failures, none reached its threshold, and nothing alerted. If an alert counts the component that noticed instead of the fault itself, a spread-out fault will never trip it.

What happens to a message nobody can see? When a thread is handed to a person, the machine should stop answering. It should still tell the person when the customer writes back. “Do not act” and “do not mention” are different instructions, and in one of our systems they were treated as the same one. The message that reached nobody was a pricing question, which is the event the system exists to produce.

My position: audit the exit, not the narrative

A monitoring habit built on reading logs will fail on exactly the days it matters. Logs are written to be read, and a crash that happens after a convincing preamble produces a convincing log. The check that caught my lane was mechanical: take every job, take its final status, and put them in one place.

I would go further. If a vendor cannot show you a per-job final status that is separate from the job’s own commentary, assume you will find out about a failure from a customer, not from the system. That is a poor way to learn that something stopped working six days earlier.

For a home-services business, the stakes are plain. The system that is meant to answer a missed call or follow up on an enquiry has one task. If it can crash after saying hello and still look fine, you lose the enquiry and you also lose any chance of knowing why.

What to do this week

1. Pick one automated task you rely on, such as call capture, a text-back or a follow-up. Find out what it reports at its very end, not at its start.
2. Ask whether that final report can mean two things. If a number or word is used for both success and failure, ask for it to be split.
3. Ask where a failure shows up if it happens three times in three different places. If each place counts only its own, the total will never reach anyone.
4. Look at your own product the way a customer sees it, not the way your dashboard shows it.

My question for you: what in your stack tells you a job finished, rather than that it started?

Have the same doubt? Bring it to a free 30-minute call, no pitch deck → https://aethonautomation.com/book?utm_source=blog&utm_medium=organic&utm_campaign=objections-t155