What happens when an automation breaks?

Why should a workflow stop instead of guessing?

Because a stopped workflow costs you an hour of manual work, and a workflow that guesses can cost you a client relationship. The asymmetry is not close.

Automations fail in three ways, and they are not equally bad:

• Loud failure. The workflow stops, throws an error, and someone finds out. Annoying, cheap, easy to fix.
• Silent failure. The workflow stops running and nothing happens. No error, no output, no signal. You discover it when a client asks why they never got a quote.
• Confident wrong output. The workflow runs, and produces something plausible and incorrect. The worst outcome, because it propagates. Wrong data lands in the CRM, wrong figures land in a report, and the corrections cost more than the original task ever did.

Design for the first one on purpose. Every ambiguity the workflow encounters should resolve toward stopping, not toward proceeding on an assumption. A step that cannot determine which client a document belongs to should park it for a human, not pick the closest match.

What actually breaks in practice?

Almost never the clever part. In practice the failures are boring and predictable, which is good news, because boring failures can be designed for.

The recurring causes:

• Credentials and tokens expiring, or being revoked when someone leaves
• A provider changing their API, or retiring an endpoint you depend on
• Rate limits during a busy week that never triggered in testing
• Someone renaming a column, a folder or a pipeline stage in the CRM
• An input arriving in a shape nobody anticipated, such as a scanned PDF where the workflow expected an email body
• Duplicate triggers firing the same job twice
• A vendor outage that lasts forty minutes
• A model step returning something outside the expected format

Note how many of these are caused by ordinary business activity rather than technology. The most common single cause of a broken workflow in a small firm is a person tidying up a system they had every right to tidy up. That is a design problem, not a discipline problem.

What does monitoring look like for a small firm?

Not a dashboard, and not a monitoring product. Three signals, delivered to a person, are enough for almost any professional practice.

1. A heartbeat. When the workflow runs successfully, it says so somewhere: "Friday report assembled, 14 matters included, 2 skipped." Without this, a workflow that dies silently is indistinguishable from a quiet week.
2. A failure alert. Immediate, to a named person, with enough detail to act.
3. A weekly summary. Volume, exceptions, and anything parked for review. This is what tells you whether the workflow is still worth having.

The heartbeat is the one that gets cut to save effort, and it is the one that matters most. Alerts only tell you about failures the workflow was able to notice. A heartbeat tells you about the failures it could not.

A good alert answers four questions without anyone having to open a log:

1. What broke, in plain language.
2. Which record or client it concerns.
3. What the workflow did and did not complete, so you know whether the job is half-done.
4. What to do manually in the meantime.

Who should get the alert?

A named person, never a shared inbox alone. Alerts sent to info@ are read by everyone, which means they are read by no one.

Set it up like a roster, not a broadcast. One owner receives the alert. If it is not acknowledged within an agreed window, it escalates to a second person, usually the principal. That is the whole design. It works because responsibility is unambiguous.

Two habits keep it healthy. Route alerts somewhere people already look, whether that is a specific person's email or a team channel, rather than a tool they have to remember to check. And treat alert noise as a fault in its own right. If a workflow cries wolf twice a week, it will be muted within a month, and the alert that mattered will be muted with it.

What should a sane support arrangement cover?

The distinction between a fault and a change, in writing, before the build. Nearly every dispute about automation support comes from that line being left vague.

A reasonable arrangement covers:

• What counts as a fault. The workflow no longer does what it was documented to do. This should be fixed under the arrangement.
• What counts as a change. You want it to do something new, or a business process changed. Priced separately, quoted before the work.
• Third-party drift. A provider changes their API and the workflow needs adjusting. Somebody has to own this. Say who.
• Response windows. In business hours, in your timezone, with a stated target rather than a vague promise.
• Keys and accounts. They should be in your name from day one. If a build sits in a contractor's account, an argument about an invoice becomes an argument about your operations.
• Documentation. A current runbook: what the workflow does, what breaks it, how to run the process manually, and who to call.
• The manual fallback. Every automated process needs a documented way to do it by hand. That is what you fall back to during an outage, and it is what a new staff member learns from.

A fixed fix window after handover, followed by an optional ongoing arrangement, is a fair structure. What is not fair, to either side, is an open-ended expectation with no written scope.

How do you know it is working again?

You reconcile, rather than assume. A fixed workflow is not the same as a recovered one, because everything that failed while it was down still has to be dealt with.

After any outage, work through four steps: replay or manually process the items that failed, count them against what should have been processed in that window, spot-check a handful of records for correctness rather than just completion, and write two lines in the runbook about what broke and what changed. That last step is what stops the same failure being diagnosed from scratch a year later.

What to do next

If you already have automations running, audit them against this in an afternoon.

1. For each workflow, ask how you would find out if it stopped today. If the answer is "a client would tell us", add a heartbeat.
2. Check every step that writes data or sends a message. Confirm it stops rather than retries.
3. Name an owner for each workflow and route alerts to them personally.
4. Write the manual fallback for your most important workflow on one page.
5. Get the fault-versus-change line agreed in writing with whoever supports the build.

Fail-safe behaviour is one of the rules Shift builds to, because it costs almost nothing at build time and it is expensive to add after something has quietly gone wrong. Whoever builds yours, insist on it before the first workflow goes live.