Help Centre › Building Processes
Even a well-built process hits the occasional hiccup – a slow page, a brief network blip, an element that loads a moment late. Per-step retry and continue-on-fail settings let a step recover from these on its own, so a momentary problem doesn't end the whole run. These settings sit alongside the exception connection and Try-Catch, which handle errors that can't simply be retried.
1. The per-step settings
On a step you can set:
- Max retries – how many times the bot re-attempts the step if it fails.
- Retry delay – how long to wait before each re-attempt.
- Backoff – how the delay grows between attempts: fixed (the same wait every time) or exponential (the wait roughly doubles each time, easing pressure on a struggling system).
- Continue on fail – if the step still fails after its retries, log the problem and carry on down the normal (DEFAULT) path instead of stopping the run.
By default these do nothing – a step runs once and, if it fails, the run follows the step's exception path or stops.
Tip: Only enable retries on steps that can succeed on a second attempt – a slow page, a brief network blip, an element that loads late. Retrying a step that failed for a real reason just wastes time and credits.
2. Which failures are retried
Retrying only helps for transient problems. The bot automatically retries failures that are likely to pass on a second attempt:
- An on-screen element that wasn't found yet
- Server errors (HTTP 5xx) and timeouts
- Other unexpected, unclassified errors
It will not retry failures that won't fix themselves – retrying would just waste time and credits:
- Bad data or bad configuration
- A business rule that rejected the work
- Access denied (HTTP 401 / 403)
- A captcha challenge
- Missing credentials
This is why a step sometimes retries and sometimes fails immediately – the bot looks at why it failed before deciding. You can see the attempts and the outcome in the run log and history.
3. Continue-on-fail vs error handling
- Continue on fail – best for a non-critical step where you'd rather note the problem and keep going.
- Exception connection / Try-Catch – best when a failure needs its own recovery path (log it, notify someone, clean up).