The Cost of Automations That Stop Silently

The tolerated pain is automation people trust without watching

Once a workflow has run successfully for weeks or months, people stop thinking about it. That is normally the point of automation. But invisible execution creates a new operating risk: the business can become dependent on a process that nobody is actively observing.

A connection expires. A connector changes. A permission is removed. A source system returns unexpected data. The automation fails, but the customer request, payment notification or operational handoff simply never reaches the next step. Nothing visibly breaks. Work just stops arriving where it should.

That is what makes the pain tolerable for so long. A manual process that stops is noticed within hours because a person is standing in the gap. An automated process that stops can stay silent for days, because the people downstream assume no work means no demand.

Why silent failures survive

Many automations are built as projects rather than operated as production systems. The builder tests the happy path, turns the workflow on and moves to the next problem. Monitoring, ownership, alert routing and exception handling are treated as optional extras.

Platform defaults rarely close that gap on their own. Microsoft's Power Automate documentation on flow failure notifications makes the issue explicit. Per-run alert emails are sent only when the platform recognises a known, fixable cause, such as a broken connection or a throttled action. A general action failure with no specific fix generates no per-run email. After one alert, a 28-day cooldown applies before another per-run alert is sent for the same flow. Alerts go to owners and co-owners, never to environment or tenant administrators, and they are not enabled for every flow by default. The administrative Monitor view shows every failed run; the inbox does not.

Microsoft's own monitoring guidance states that flows are not set-and-forget solutions. It points to run analytics, environment-level reporting, longer run history and custom alerts through Application Insights for production flows where standard notifications are not enough. The tools exist. What is usually missing is the decision to use them and the person accountable for doing so.

The operational consequences

When a workflow fails quietly, the damage shows up somewhere else in the business, usually as an unexplained gap:

• sales notices that web enquiries have dried up, but assumes the market is quiet;
• a customer chases a quote, order confirmation or refund that was never generated;
• finance finds payment notifications or invoices missing during reconciliation;
• a new employee starts without system access because the provisioning step never ran;
• a compliance submission or reminder misses its deadline.

Microsoft's guidance on fixing connection failures describes the most common causes in plain terms: expired tokens after password changes, permissions removed or blocked by data-loss-prevention policy, renamed or deleted lists and mailboxes, rate limits, and flows suspended after repeated failures. It also warns that a trigger condition can filter out every event, so a flow can appear healthy while doing nothing. None of these is exotic. Each is a routine change somewhere else in the estate that the automation was never told about.

How the pain becomes money

• Missed transactions: requests, records or notifications never reach the next stage.
• Revenue delay: leads, invoices, renewals or fulfilment steps wait until somebody notices.
• Rework: employees reconstruct what should have happened and manually replay failed work.
• Customer service cost: complaints become the monitoring system.
• Support labour: technical teams investigate failures without clear run history or ownership.

The commercial signal
If the first reliable alert that an automation failed is a customer complaint or an employee asking why work is missing, monitoring is weaker than the business dependency.

Use a failure-cost model that follows the process

Failure exposure per incident
missed items × average correction minutes × loaded labour cost + contribution margin genuinely lost or delayed

Detection-delay exposure
failed items accumulating per hour × hours before detection × average recovery cost per item

Do not assume every failed automation creates revenue loss. Some failures only delay work. Separate recoverable backlog from permanent loss, and measure the actual cost of correction.

A worked illustrative example

Every figure below is an illustrative assumption, not a benchmark. Replace each one with your own volumes, rates and margins.

A flow routes web quote requests into a sales queue. Its connection expires and it stops. Nobody notices until a customer phones to ask about an unanswered request.

Now assume the same failure is detected within two hours by a shared alert or a volume check. At 5 requests an hour, 10 requests are affected. Correction takes 10 × 12 minutes = 2 hours × R350 = R700. The investigation still costs R2,400, and in this illustration no work is lost. The incident costs R3,100.

The difference, R23,575 per incident, is almost entirely the price of detection delay. If a failure of this kind happens four times a year, illustrative exposure is R106,700 with slow detection against R12,400 with fast detection. Notice where the money sits: most of it is lost contribution and backlog growth, not the technical fix.

Monitoring must cover more than technical errors

An automation can technically succeed and still produce the wrong business outcome. A workflow might run but process zero records because its trigger stopped receiving data. It might complete while routing information to the wrong destination. Good monitoring therefore covers both technical execution and business expectations.

Useful controls include run history, failure rate, expected volume, stale-item checks, exception queues and ownership. The aim is not a dashboard for its own sake; it is evidence that the process is still doing what the business depends on it to do. A simple rule such as "alert if fewer than ten requests arrive by midday" often catches failures that no error message ever will.

When this becomes commercially urgent

Priority is high when automation touches money, customer communication, sales leads, employee access, fulfilment, compliance deadlines or other time-sensitive work. It is also urgent when a workflow has one owner, uses an employee account, has no shared alert destination or has repeatedly failed because of expired connections.

Two further triggers deserve attention. The first is staff change: when the person who built a flow leaves, their connections and alert emails can leave with them. The second is growth: as more processes are automated, the number of quiet failure points rises faster than anyone's ability to remember them.

What good looks like

A production automation has a named owner, a backup owner, clear expected outcomes, alerting, run-history access, exception handling and a documented recovery path. Important failures go to a shared operational destination rather than one person's inbox. Changes are tested and monitored after deployment.

The wider principle is covered in who watches the automations and why every automation needs a failure path. Reliability is an operating discipline, not a feature of the tool.

Practical next actions

1. Inventory automations that move money, customer work, access or operational commitments.
2. Confirm each has a named owner and backup owner.
3. Review which failure types generate alerts and which require central monitoring.
4. Add shared failure notifications for critical workflows.
5. Monitor expected transaction volumes as well as technical run status.
6. Create an exception queue and a documented replay/recovery process.
7. Review failures and recurring causes as operational data.

Bottom line

Automation does not remove operational responsibility; it changes where responsibility must sit. The more invisible the execution becomes, the more deliberate monitoring needs to be. Otherwise the business saves labour on normal days and pays it back with interest when failures accumulate unnoticed. The cost of a silent failure is set less by what broke than by how long nobody knew.

Sources and further reading

• Understand flow failure notifications in Power Automate - Power Automate (last verified 10 October 2026)
• Monitor your flows - Power Automate (last verified 10 October 2026)
• Fix connection failures in cloud flows - Power Automate (last verified 10 October 2026)

Related Mellorca reading

• Manual Automation Triggers Leave Half the Process Manual
• Paper Forms Captured Twice: The Cost of Double Handling
• Gathering Information Before Work Can Start: The Payroll Cost of Preparation