How we built centralised failure monitoring for a fleet of automations
A lightweight relay now runs around the clock, collecting unexpected crashes and handled exceptions, preserving their severity, and sending one consistent alert to a monitored inbox.
- 4 min
- 7 workflow steps
- 5 monitoring stages
- Live system
Client details withheld for confidentiality. System details and recorded figures are real.
How do you monitor a fleet of automations?
One relay listens for two kinds of news: an automation crashing unexpectedly, or an automation that handled a problem itself and files a deliberate report. It reshapes both into one consistent format and sends a single alert to a monitored inbox, so there is one place to look rather than a different alert style for every automation.
We had handed real paperwork over to automation, and the worry was never whether it would work. It was whether we would know when it did not.
If an order quietly failed on a Friday afternoon, nobody wanted to discover it the following Thursday when a customer chased. The firm wanted one place where every hiccup, big or small, showed up straight away, without anyone having to remember to go and check.
What the finished system does
The relay now watches the whole fleet. When any automation crashes, the relay catches it automatically; when an automation handles a problem itself, it files a deliberate report. Both are reshaped into one consistent alert and delivered to a single monitored inbox, so finding a failure no longer depends on someone remembering to check each automation separately.
We design managed automation systems like this around the tools a team already uses.
How the system works, stage by stage
Catch unexpected failures
Fires automatically the moment any workflow in the fleet dies unexpectedly.
Receive handled reports
Receives deliberate reports from workflows that handled a problem themselves, such as an order sent to review or a backup that failed.
Accept secured reports
Receives the same reports through an authenticated endpoint, giving workflows another reporting route when that better suits how they run.
Standardise the message
Reshapes both kinds of news into one identical format, while preserving severity, so a genuine crash never reads like a routine review flag, and vice versa.
Send one consistent alert
Sends one consistently formatted alert email to a monitored inbox, the same layout every time.
Why this was more than an email on error
Sending an email when a workflow breaks is easy. Making monitoring a small firm can actually rely on is harder, because a fleet of automations produces many kinds of news, and the part that reports failures is the part that can least afford to fail quietly.
The safeguards that make it dependable
One bell, one format
Every automation reports to the same inbox in the same layout, so there is one place to look rather than one alert style per process.
Severity preserved
A genuine crash is never reshaped to read like a routine review flag, and a routine flag never reads like a crash.
Two reporting routes
Unexpected crashes are caught automatically; workflows that handle a problem themselves file a deliberate report through a secured route.
Independent of the business systems
The relay does not call the inboxes, spreadsheets, or other business tools involved in the original workflow, which reduces the chance that the same downstream problem affects both the workflow and its alert.
Deliberately minimal
A handful of steps and no business logic, so the alert path has few moving parts and fewer ways to fail.
The relay is intentionally small. It receives an event, preserves its severity and context, and hands a consistent alert to the monitored inbox. It does not rerun jobs, update records, or call the business systems involved in the original failure.
Keeping business logic out of the relay gives the alert path fewer moving parts and fewer opportunities to fail.
In live operation
The relay is the always-on monitoring layer for the fleet.
Across the retained run history, the relay completed every event it received and handed off each alert in under one second.
Questions businesses ask
How do you monitor unattended automations?
One relay listens for two kinds of news: an automation crashing, and an automation that handled a problem itself and files a deliberate report. Both are reshaped into one consistent alert and sent to a monitored inbox, so there is a single place to look rather than a separate check for each process.
What happens if the monitoring itself fails?
The relay is kept minimal and separate from the business systems it watches, which reduces its failure points. Detecting a complete relay or automation-platform outage would require an independent external uptime check.
How do you tell an urgent crash apart from a routine flag?
Severity is preserved when the message is standardised, so a genuine crash is never reshaped to read like a routine review flag, and a routine flag never reads like a crash.
Do you need a separate alerting tool for every automation?
No. Every automation reports through the same relay in the same format, so a fleet of automations produces one consistent alert style and one inbox to watch, not one per process.
Where does a person still get involved?
A person reads the monitored inbox and acts on what an alert says. The relay's job is to make sure nothing that needs attention stays silent, not to decide what to do about it.
Want a system like this in your business?
Tell us what eats your week. We will tell you what can be automated, what should stay human, and what a first version would involve.
No build cost · Clear terms upfront · Managed by Noventra