Plan for the day it breaks

Exit

Lesson 7 · 8 min

Plan for the day it breaks

By the end

A one-page break plan for one automation: how you’ll notice, who gets told, and how the work gets done by hand.

  1. 1Learn
  2. 2Try it
  3. 3Human check
  4. 4Quick check

Learn · 3 min

Loud failures and quiet ones

Every automation breaks eventually. Loud failures stop a run with an error: a connection expires after a password change or when someone leaves, a connected tool is down, or you hit your plan’s usage limit (some plans keep running and charge for the extra instead). Your automation tool usually records these in its run history and can email someone. Annoying, but at least you know.

Quiet failures are worse, because nothing looks wrong. Someone renames a spreadsheet column and the report reads the wrong cells. The form gains a field and inquiries arrive half-empty. The AI model behind a step is updated and its labels drift. Or the trigger stops firing, and silence looks exactly like a slow week.

Logs, alerts and a heartbeat

Three things make failures visible, loud or quiet, and none of them needs code:

  • Logs: know where your tool’s run history is, and add a log sheet with one row per run (time, what came in, what it did) that anyone can read.
  • Alerts: send error emails to a named person and a backup, not a shared inbox nobody reads. If the person hasn’t acknowledged an alert by a set time, the backup takes over.
  • A heartbeat: a short daily or weekly summary that proves the automation ran, like “23 emails labeled, 3 UNSURE, 0 errors.” Zero emails labeled, or no summary at all, is the alarm, so someone has to be expecting it.

The fallback is the manual way, written down

When it breaks, the work still has to happen. Write the manual steps on one page: where work comes in, who handles it by hand, and what to tell customers if replies are slower. Keep the old templates and checklists; they’re your fallback. Work done by hand gets the same approvals as the automation.

Decide who can pause the automation, and what happens after a fix: a person finds the work that arrived during the outage and handles it, and a person switches the automation back on only after it passes your test cases again.

Write down who fixes it (whoever built it, or whoever you’d call) and how to reach them. Then check the plan twice a year: people leave, and alerts keep going to their old address.

Try it on your business

5 min

Write the break plan for one automation you run or plan to run. Five minutes now saves a bad morning later. Tool cost: none.

  1. 1

    Fill in the prompt for one real automation, run it, and cross out any failure that doesn’t apply.

  2. 2

    Add any failure your team has already seen; those are the likeliest.

  3. 3

    Name who gets alerts, their backup, and how long an alert can go unanswered before the backup takes over.

  4. 4

    Save the plan where the backup can find it, and put a weekly log check in someone’s calendar.

Help me write a one-page break plan for an automation at [BUSINESS].
What it does: [TRIGGER, STEPS AND WHERE THE OUTPUT GOES]
Who relies on it: [PEOPLE OR CUSTOMERS]
How often it runs: [HOW OFTEN, e.g., every new email, or Mondays at 7am]

List:
1. The five most likely ways it could fail for this setup, loud or quiet.
2. For each, how we'd notice within a day, and who gets told.
3. The manual steps to do the work by hand until it's fixed.
4. What to check before switching it back on.
Use plain language and keep it to one page.
Open ChatGPTOpen ClaudeOpen Gemini

Human check: before you use it

Quick check · question 1 of 2No grades

Which failure is hardest to notice?

Ask the Distillery

Answers come from The Distillery’s own pages, with sources.

If the Distillery doesn’t know, it says so and points you to a person.