Lesson 6 of 7
Errors & reliability
6 min read
One morning a step just… fails. The email service is down for a minute. Does your whole scenario crash — or shrug and carry on?
When a step fails
Modules talk to the outside world, and the outside world hiccups: a service times out, a login expires, a row is malformed. When a module fails, by default the run stops right there — the steps after it never happen. Reliability isn't about never failing; it's about deciding what happens when a step does.
A failure with no plan stops the whole run. The fix isn't to hope it never fails — it's to plan for when it does.
Retry, then a handler
Two tools catch a failure. A retry simply tries the step again after a moment — perfect for a passing blip like a brief timeout. But if the error is persistent — a bad card, a missing field — retrying won't help. For that you add an error handler: a branch that catches the failure and routes it somewhere useful, so the scenario ends gracefully instead of crashing.
Retry fixes the temporary; a handler catches the permanent. Together they turn a fragile scenario into one you can trust to run unattended.
Silently swallowing every error hides real problems. A good handler still tells someone — logs it, messages you — so a quietly-failing scenario doesn't look healthy while dropping work.
The shape of it
- —By default, a failed module stops the whole run.
- —A retry re-tries a step — good for a temporary blip.
- —An error handler catches a lasting failure and routes it, so the scenario ends gracefully.
A module fails because a card was permanently declined — retrying gives the same error. What actually keeps the scenario reliable?
Continue in the app
Take the whole Make for AI course — tracked
Get your personalized path, progress and streaks in the app — this lesson and every next one, in order.