Save Progress Automatically as You Run
RTILA X checkpoints capture the current command position, collected data, and URL state so recovery is seamless.
The Anatomy of an Automation State
A running automation includes many moving parts. It has the current command position, the URL being viewed, the values sitting in variables, the rows collected so far, and the state of pagination loops. When a crash occurs, recreating that state from the project file alone is difficult. The automation would need to guess where it stopped and what data was already captured.
RTILA X solves this by saving a checkpoint snapshot of the execution state. The checkpoint contains enough information to resume the run as if the interruption never happened. When you restart the workflow, RTILA X loads the checkpoint, restores the collected data and variable values, and continues from the next command.
What Gets Captured
A checkpoint includes the current command position, so RTILA X knows exactly which step to run next. It also includes processed URL history, collected dataset rows, pagination progress, variable values, and important session context such as browser profile state.
The collected data is important. Without saving extracted rows, a resume after a crash would repeat the extraction and duplicate records. Checkpoint data prevents that duplication and keeps the output clean.
Local Storage and Privacy
Checkpoints are stored in project data on your machine. There is no cloud recovery service required and no automatic remote sync. The checkpoint state remains under the same local-first model as the rest of RTILA X.
This also means you can inspect or delete checkpoint files through the project folder when needed. For sensitive workflows, the checkpoint data stays local and is removed with the project if you choose to delete it.
Configuring Checkpoint Frequency
More frequent checkpoints reduce the amount of work that may be lost after a crash, but they consume a small amount of CPU and storage. RTILA X lets you choose a frequency that fits the importance and length of the workflow.
Short workflows may use sparse checkpoints with little risk. Long crawls or client-critical runs benefit from more frequent snapshots. The configuration is per project, so different workflows can use different policies.