Lessons 88.1–88.3 built the happy path: verified events, a chosen home, narrow keys. Now the unhappy paths — because every workflow meets them in its first month. A vendor is slow. The same event arrives twice. A customer replies with something nobody predicted. The question isn't whether exceptions happen; it's whether each one has a designed landing place or explodes on a customer.

The vocabulary, in plain language

• Exception: any run that can't complete normally — bad input, failed verification, vendor error, timeout. Not a bug to hide; a case to route.
• Backoff: waiting progressively longer between retries (seconds, then minutes) so you don't hammer a struggling vendor — politeness with a timer.
• Timeout: the maximum wait before giving up on one attempt — every external call gets one, or one slow vendor freezes your whole queue.
• Idempotency: from Lesson 88.1 — duplicates produce one result. Worth repeating because duplicate delivery is normal, not rare.
• Manual-review queue: the list of runs needing a human — with the payload, the error, what was already tried, and a named owner. The deliberate slowing-down place from Part XVI's rules.
• Runbook: the one-page "when X happens, do Y" instruction the reviewer follows (full treatment in Lesson 89.3).

The mental model: airport operations. Most flights board normally; but every flight has a plan for delays (backoff), diversions (error queue), duplicate bookings (idempotency), and the gate agent with authority to decide (human queue). Nobody designs an airport with only sunny weather in mind.

The five failures every workflow must handle

Write these onto the contract before launch — not after the first incident:

1. Malformed input — missing fields, wrong types, garbage bytes. Response: validate, reject to the error queue with the reason, alert nobody at 3 a.m. (it's the sender's problem to fix), log it. 2. Vendor delay / outage — the CRM or email API is slow or down. Response: timeout each attempt, backoff retries (e.g. 1 min, 5 min, 30 min), then park in the review queue — never lose the job, never retry forever. 3. Duplicate event — same event ID twice (retry or double-click). Response: idempotency lookup → acknowledge, no second side effect. Test this; Stripe documents it explicitly in Stripe webhooks. 4. Unexpected reply / content — the human writes back something the classifier never saw ("just cancel everything and call my lawyer"). Response: route to the human queue with full context; the workflow never improvises on surprises. 5. Human takeover — the owner pulls the brake: pause the workflow, finish the run manually, record what happened. Every workflow needs a stop switch and a named person allowed to pull it (see kill switches in Lesson 89.2).

Platform help exists: n8n docs error workflows, Make help incomplete-execution handling, and Zapier help replay and error alerts all implement versions of retry + queue. Learn your platform's version — then verify it matches the five cases above rather than assuming it does.

Exercise: put five failures on the contract

Reopen the AUTOMATION-CONTRACT.md from Lesson 84.3 and append:

## Failure cases (all five, no blanks)
1. Malformed input — detect: ___ / action: error queue ___ / owner ___ / alert? ___
2. Vendor delay — timeout ___s / backoff ___ / max attempts ___ / then ___
3. Duplicate event — idempotency key ___ stored in ___ / on dupe: ___
4. Unexpected reply — examples ___ / route to ___ with ___ attached / SLA ___
5. Human takeover — stop switch ___ / who may pull ___ / resume procedure ___

## Review queue
- Location: ___ / fields per item (payload + error + attempts + owner): ___
- Review cadence + owner: ___ / aging rule (unreviewed > ___ → escalate to ___)

Worked mini-example — booking deposit flow: malformed payload → error queue with "missing amount_cents"; payment API slow → 10s timeout, retries at 1/5/30 min, then human queue; duplicate webhook → entitlement check catches it, no double booking; customer replies "my card was stolen" → immediate human escalation, workflow never replies; owner pauses the flow during a provider outage via the platform's scenario switch, processes two deposits manually, logs both.

Finish line: a contract with all five failure cases filled — detectors, actions, owners, and a review queue with an aging rule.

Verify quickly: simulate each failure with a test run (bad payload, killed vendor mock, double delivery, weird reply, manual pause). If any simulation has no designed landing place, the contract is incomplete.

Common failure mode: infinite hope — retrying forever with no backoff, no timeout, and no queue, so one stuck run blocks everything and the log fills with thousands of identical errors. Retries need a budget; budgets need a queue.

Check your understanding

1. Why do retries need both a timeout and a backoff — what breaks without each? 2. What's the difference between the error queue and the manual-review queue? 3. Who may pull the stop switch, and what happens after they do?

Next

Your workflow now fails gracefully. But is it worth running at all? Lesson 88.5 measures automation value — baseline, exception rate, time saved, error cost — before you expand anything.