Skip to main content
Figranium provides several mechanisms to make your automation tasks resilient to failures, from optional actions to retry loops and fallback sub-tasks.

​
Why Tasks Fail

Common failure modes in browser automation:

Timeouts

An element takes longer than expected to appear.

Popups & Modals

A popup or modal interrupts the expected flow.

Network Failures

A network request fails or times out.

Stale Selectors

A selector becomes stale after a navigation.

CAPTCHA

A CAPTCHA is triggered.

Dynamic Content

Dynamic content changes the page structure.
A well-designed task anticipates these failures and handles them gracefully.

​
The On Error Block

The On Error block is Figranium’s primary error handling mechanism. It works like a try/catch: if any action in the main flow raises an error, execution jumps to the on_error block.
The on_error / end pair should be placed in the task to catch errors from preceding actions. Any error thrown by an action before the on_error block is caught.
The simplest use: place an empty on_error/end block to absorb errors from an action that may or may not exist:
Perform a fallback action when the primary approach fails:
Log the failure and stop the task cleanly:

​
Retry Patterns

​
Retry with a Counter Variable

Use a while loop combined with a counter to retry a failing action up to N times:
This retries up to 3 times with a 2-second pause between attempts, then continues if any attempt succeeds.

​
Retry a Login

​
Handling Popups and Modals

Popups that appear unpredictably are a common cause of task failures. Handle them proactively.

​
Check and Dismiss Before Proceeding

​
Dismiss Any Popup on Every Page

Use a sub-task triggered via start to handle common popups at the beginning of every task:
See Modular Workflows for more on reusing sub-tasks across multiple parent tasks.

​
Timeout Strategies

Each action block can have its own timeout (in milliseconds). Use shorter timeouts for elements that should appear quickly, and longer ones for slow-loading content.
Use on_error around short-timeout actions to make them non-fatal when the element doesn’t appear.

​
Logging Errors for Inspection

Use a javascript block inside on_error to log diagnostic information to the execution output:
The returned object appears in the execution detail view, giving you context about what the page looked like when the failure occurred.

​
Output Provider Error Handling

When using Output Providers, you can control what happens if the data push to an external service fails:
  • onError: "ignore" (default): The execution is marked as successful even if the push fails.
  • onError: "fail": The execution is marked as failed if the push fails.
Choose fail when data delivery is critical and you want alerts on push failures.
Always include a termination condition in retry loops. An unbounded while loop with no exit condition will run until the task times out.
Combine on_error blocks with JavaScript Execution to capture rich diagnostic data when failures occur.