Every workflow that talks to other apps hits a failure sooner or later, and usually not because anything in it is wrong. An app is busy for a minute. A key expires. Someone archives the Slack channel a workflow posts to, and the next run stops with "Slack API error: is_archived: this channel is archived: unarchive it or pick another channel".
By default, a failed step stops the run, so nothing after it runs on bad data. That's the right default, but it shouldn't be your only option. Here's everything Lodol gives you for failures, from catching them before the first run to getting a failed run back on track, including this week's additions: retrying a run from the step that failed, choosing who hears about a failure, and finding any run.
The short version
| When | Reach for |
|---|---|
| An app is briefly busy or slow | Try again on the step |
| One bad record shouldn't stop the rest | A Try / Catch, or Carry on |
| An API's 404 just means "not found" | Call an API's Error responses |
| The right person should hear about it | When this workflow fails, in Workflow settings |
| A failure should start other work | The Workflow failed trigger |
| You've fixed the cause | Retry from failed step |
Catch problems before the first run
- Saving checks the workflow. A value that doesn't exist, or a schedule that can't run, is caught when you save, with a suggested fix.
- Empty fields stop early. A step with an empty required field stops before it reaches the app, with a sentence naming the field.
- Turn a step off while you fix it. Disable a step from its menu, a right-click or the D key. The run skips it, and any step that reads its values is flagged.
Decide what each step does when it fails
Every step that does something has an If this step fails setting, with three choices:
- Stop the workflow. The run stops there and is marked failed.
- Try again. For a problem that may pass, like a service that's busy or slow to answer. Choose between 2 and 10 attempts in all, with a growing pause between them. A mistake in the step itself fails at once, because trying again wouldn't fix it.
- Carry on. The run goes on without the step, and later steps can read what went wrong from its result.
Set a default for every step in the workflow's settings, under When a step fails, and change it only on the steps that need something different. Separately, app steps already retry on their own when an app is briefly unreachable, and Integration retries in Settings sets how many times and how long to wait.
Give the run a plan B
Sometimes the answer to a failure is to do something else. Wrap steps in a Try / Catch, and if one of them fails, the steps under On error run instead of the run stopping. Post the alert to Slack, and if Slack is down, send it by email. The error is saved too, with what happened and what kind of failure it was, so the plan B can say what went wrong.
The same shape handles "find the customer, or create them if they're new": try the lookup, and create the record when it fails. And in a loop over a hundred invoices, a Try / Catch around each one means one bad invoice doesn't stop the other ninety-nine.
Call an API has one more choice. An error response, such as a 404 that just means "not found", can come back as a result for later steps to check, instead of failing the step.
Hear about it, without a flood
When a run fails, Lodol tells you straight away. The email, "Your workflow run failed", quotes the error, and its button opens the run. The same notice appears in Lodol, and in Slack if you've set your notifications to arrive there.
New this week, each workflow chooses who hears. In its Workflow settings, under When this workflow fails, the person each failing run ran as is told, and you can add teammates, so the billing workflow's failures reach whoever looks after billing. A workflow that keeps failing sends one notice when it starts failing, then a summary of later failures, not an email for every run. A step only counts once its retries are used up, and a step set to Carry on doesn't count at all.
When a failure should set off work of its own, such as opening a ticket for whoever's on call, build a workflow that starts from the Workflow failed trigger. It runs when one workflow you choose fails, or any other workflow in the workspace, and receives the workflow, the step, the error and a link to the run.
Fix it, then retry from the step that failed
Open the run and the step that stopped it is marked, with its error. Fix the cause: reconnect the app, unarchive the channel, change the step. If you build with Claude or ChatGPT connected to Lodol, you can ask it to read the failed run and fix the workflow.
Then, new this week, choose how to try again:
- Retry from failed step runs the workflow again from the step that failed, with the data the original run started with. The steps before it don't run again, so a row that was already added isn't added twice. If your fix was to the step that failed, the retry picks it up.
- Retry from start runs the latest version of the workflow from the beginning, with the same original data.
Both work for runs a trigger started, not only ones you started by hand, because the retry keeps what the trigger handed over: the same Stripe payment, the same form response, the same email. Each retry is a new run, linked to the one it retries, so the history stays readable.
Each failed step also says whether trying again is likely to help. When it isn't, Lodol asks before retrying, because some failures won't pass on their own, and a step may already have done its work, such as sending an email, before it failed.
Find any run
The Runs page lists every run, including the ones triggers started. Now you can search runs by anything in them, such as an email address or an order number, filter them by date and workflow, and export what you find. "Did the refund for order 4417 go through?" becomes a search instead of a scroll.
What none of this does
- It doesn't undo finished steps. A run that fails or is stopped keeps what it already did: a message it sent stays sent.
- Retrying from the start repeats everything. For a workflow that emails a customer early on, retry from the failed step instead.
- Carry on doesn't make the problem go away. The error is in the step's result, and the steps after it have to check it.
That's the design. Lodol tells you exactly what failed, keeps what already happened on the record, and leaves the decision about what to do next with you, or with a plan you wrote down in advance.
Give your most important workflow a plan B.
Open its Workflow settings, choose who hears when it fails, and set the steps that talk to a busy app to Try again. The guide to handling failures covers every option, and the Runs page shows what living with your workflows looks like. Start free if you don't have a workspace yet.