Triggers and Invocations

An executable stores one recurring schedule: cron or interval. Manual runs and webhooks add invocations without replacing that schedule. Configure triggers in the console or through the management CLI/API.

Interval

{ "type": "interval", "intervalMs": 60000 }

An optional startAt is an epoch timestamp in milliseconds. When it is in the future, schedule registration is deferred until that time; subsequent runs follow the interval. The console exposes presets and a start-date input.

Cron

{ "type": "cron", "cronspec": "0 * * * *" }

The example runs at minute zero of each hour. Use the console's expression preview and verify the displayed next runs for your environment. Changing a trigger replaces its schedule registration; do not rely on the old cadence continuing during a configuration change.

Manual and webhook invocation

Execute now requests one additional real run of an active executable. Simulate is a preview that discards storage changes and does not submit.

A named webhook invokes an active executable with predefined or custom validated args. The URL is a run-only credential, separate from management authentication. Each executable can have up to ten active URLs.

Polling and concurrency

There is no native on-chain event/log trigger in this executable model. Poll relevant chain state from a task, carry a compact cursor in storage, and return canExec: false when nothing is ready. For transaction-dependent checkpoints, advance state after confirmation using onSuccess.

Choose intervals with room for execution and confirmation. The storage lock prevents concurrent state commits, and overlapping webhook runs can be rejected rather than queued. A pause prevents new enabled invocations but does not cancel transactions already submitted.

See scheduling, persistent state, and lifecycle operations.