Skip to main content
A deployment publishes every *.automation.ts file in a project directory together. A run is the causally connected work started by a trigger event. See Deploy a project to publish code and authorize integration accounts. See Query runs to inspect execution history in the dashboard or with local SQL.

​
Project snapshots

A successful deployment becomes the project’s single active snapshot. Automate.ax builds and activates all automation files together, so a project never mixes files from two successful deployments. Each automation’s relative source path is its identity in that snapshot. Move or rename a file only when you intend to replace that automation identity.

​
Durable execution

An active trigger event creates an isolated execution. The runtime composes the automation, schedules ready actions, records outcomes, and resumes as outputs become available. Each trigger delivery starts at a root context. Fan-out and coordination create descendant contexts with their own lifecycle states. Delayed deliveries and protected callbacks are independent roots. Correlation can create a child with both the initiating and delivery contexts as parents. When investigating a run, traverse automate.context_descendants from each relevant root and query scheduled invocation provenance. See Query runs. Independent actions can execute concurrently. Dependent actions execute only after their required signals materialize. See Signals and Actions.

​
Inspect a run

Open a recent execution in the web app to follow its causal timeline from left to right. Trigger occurrences and action invocations appear in execution lanes, while connections clarify branches and joins across lanes. Long gaps are compressed and labeled with their real duration. Select an output beside an operation to preview and navigate its value. A run appears Waiting while one of its actions has an undelivered internal delay. The initiating context might already have settled at that point. Delivery later starts an independent root. The UI connects it to the initiating occurrence only if correlation creates a shared child. An automation can call markSignificant(signal) or signal.markSignificant() to highlight the causally connected run when that signal emits. For automations that use this marker, Recent runs shows significant runs by default. Turn on Show insignificant runs to reveal the complete history; insignificant rows appear dimmed. Automations without a significance marker keep the standard unfiltered run list. The Duration column shows recorded automation runtime aggregated across every context in the causally grouped run. Queue time, durable waits, deployment planning, and time between invocations aren’t included. See Plan usage.

​
Run-history retention

Your organization’s plan sets the default and maximum retention for completed execution data. Organization admins can choose a shorter supported period in Organization settings. Automate.ax removes event payloads, action and signal values, errors, logs, and other run history after that period. The retention period starts when the complete causally connected run finishes. Running, delayed, scheduled, and waiting runs remain available until they finish, even when they wait longer than the configured retention period. A correlation without a time-to-live can therefore retain the values it needs indefinitely. Use bounded coordination when your data policy requires every run to finish within a fixed period. Reducing retention permanently removes eligible history during the next cleanup. Increasing it doesn’t restore deleted data. You control local database copies and exports created with the command-line tool, so you must remove them separately.

​
Retries and resumptions

Automate.ax stores action outcomes and dependencies durably. If an executor stops, Automate.ax can resume from recorded work instead of treating the whole program as an in-memory process. The platform retries thrown execution failures before recording a failed action outcome. Because a provider may accept a request before a worker learns the result, actions should use provider-supported idempotency where available and shouldn’t assume several separate actions form one transaction.

​
In-flight runs

New trigger events use the active deployment. Work already executing on a published version can finish there. Later resumptions verify that the current code still matches recorded durable action identities and dependencies. Keep action call order and literal structure deterministic so in-flight work remains compatible. Before deploying a changed durable call structure, inspect active runs; wait for them to finish or preserve the action identities and dependency structure they need to resume.