The failure that costs most
Not the automation that crashes.
The automation that fails and reports success.
An error is caught, the automation exits cleanly, the orchestrator records a completed run. Nobody is alerted. The data did not arrive.
Somebody discovers it three weeks later when a report is short, and by then nobody can reconstruct what was missed.
Everything in this article is about preventing that.
Try-catch per stage, not per automation
One try-catch around the whole thing tells you something failed.
One per stage tells you which.
A file-handling automation has natural stages: download, extract, find the file, validate, upload. Each gets its own protected block.
Then the log says “extraction failed” rather than “an error occurred”, and whoever picks it up knows where to look before opening anything.
FIGURE 1: STAGES, EACH PROTECTED
Download
- Its own try-catch
Extract
- Its own try-catch
Validate
- Its own try-catch
Upload
- Its own try-catch
Log the message and the stack trace
For an unattended job, the log is all anyone will have.
Log both:
The error message. What went wrong, in words.
The stack trace. Where in the automation it happened.
Without the trace, a generic message like “object reference not set” tells you nothing useful. With it, you know the step.
And log the successful runs too. A gap in a success log is visible. Nothing at all is not.
Re-throw so the job fails
The single most important line in this article.
When you catch an error, log it — and then re-throw it.
Why: catching an error and continuing means the automation exits normally. The orchestrator marks the job successful. No alert fires.
You have converted a visible failure into an invisible one.
A failed job is a signal. It appears in the orchestrator, it triggers alerts, somebody sees it.
A false success is silence, and silence looks exactly like everything working.
The only exception: when you have deliberately decided that this particular failure should not stop the run — one bad record out of five hundred, for instance. Even then, log it and report it in a summary. Continuing is not the same as ignoring.
FIGURE 2: WHAT HAPPENS AFTER A CATCH
Re-thrown
- The job is marked failed
- It appears in the orchestrator
- Alerts fire
- Somebody looks at it
Swallowed
- The job is marked successful
- Nothing looks wrong
- No alert
- Discovered weeks later
Alerts must reach a person
A log file is not an alert.
Four requirements:
A named person. Not a shared inbox nobody reads.
Enough context to act. Which automation, which stage, what error, when.
Reaching them in time. For an overnight job, in the morning at the latest.
Including the case where the job did not run. A scheduled run that never started produces no error at all. Monitor for the absence.
That last one is the most commonly missed, and it is the failure that lasts longest — because there is nothing to notice.
Validate at each stage
Do not assume a step worked because it did not error.
After downloading: does the file exist? Does it have content? Is it the right type — a download can return an HTML error page with the extension you expected.
After extracting: were any files produced?
After finding: was a match found, and does it exist on disk?
After uploading: what did the response say? A success status with a body reading “0 rows processed” is a failure wearing a success badge.
Checking is cheap. Discovering it downstream is not.
FIGURE 3: WHAT TO CHECK AT EACH STAGE
After download
- File exists, has content, is the expected type.
After extract
- Files were actually produced.
After find
- A match was found and it exists on disk.
After upload
- Read the response, not just the status code.
Retries
Some failures are temporary. A brief network problem, a service restarting, a rate limit.
Retry those. With a limit, and with a pause between attempts.
Do not retry everything. A file that does not exist will not exist on the third attempt either — retrying just delays the alert.
A useful split: retry network and availability problems. Fail immediately on validation and logic problems.
Deciding continue-or-stop
When processing many items, one fails. What now?
Continue when items are independent. Log the failure, carry on, report everything at the end.
Stop when items depend on each other, or when a partial result would leave things inconsistent.
Decide deliberately per automation, rather than accepting whatever the default is.
And whichever you choose, you must know where it got to. A run that failed halfway with no record of what completed is the worst outcome — you cannot safely re-run and you cannot safely continue.
The run summary
Every batch automation should report at the end:
- What it processed
- What succeeded
- What was skipped, and why
- What failed, and why
Sent to a person.
Without this, a run that half-worked looks identical to one that fully worked.
Testing the failure path
The step everyone skips.
Deliberately break things and confirm the handling works:
- Point it at a URL that does not exist
- Give it an empty archive
- Make the target system unavailable
- Feed it a file with a missing required field
Then check: did the job fail? Did the alert arrive? Does the log say which stage?
An error handler nobody has tested is not error handling. It is code that has never run.
The short version
Try-catch per stage, so the log says which one failed.
Log the message and the stack trace — for an unattended job, that is all anyone will have.
Re-throw so the job is marked failed. A swallowed error becomes a false success, and a false success is silence.
Alert a named person, including when the job did not run at all.
And test the failure path deliberately. The handler that has never run is the one that will not work when it matters.
Automations that might be failing without anyone knowing?
Get in touch. We build error handling that fails loudly — and we test it by breaking things deliberately.
