Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.twine.se/llms.txt

Use this file to discover all available pages before exploring further.

Once a flow has been built, it typically runs on a schedule and is monitored through its run history and logs. Both sides of that - when the flow runs and what it records while running - are configured per flow.

​
Schedules

A flow can have a single schedule with three fields:
  • Enabled: a toggle that controls whether the schedule fires at all. Disabling the schedule does not delete it; re-enabling it resumes firing on the configured cron expression.
  • Cron expression: a standard cron string that determines when the schedule fires. The expression is evaluated on minute ticks, so the finest granularity is one run per minute.
  • Log level: the verbosity used for runs started by this schedule. See below.
Scheduled runs are enqueued with normal priority. Manual runs started from the editor use a higher priority, which means an operator’s ad-hoc run jumps ahead of pending scheduled runs. A flow without a schedule, or with the schedule disabled, can still be run manually from the editor at any time.

​
Log levels

Each flow run has a log level that gates which log entries end up in the run’s log. The available levels, from quietest to most verbose, are:
  • none - suppresses all log output.
  • warning - only warnings and errors.
  • info - the normal operating level; records each major step.
  • debug - includes detailed per-node information. Useful for investigating a specific failure; usually too verbose for ongoing runs.
The log level on the schedule is the default for scheduled runs. Manual and dry runs can override the level on a per-run basis.

​
The run log

While a flow is running, log entries written by nodes are appended to an in-run log buffer on the token and broadcast to any editor pane watching the run. When the run finishes, the buffer is snapshotted onto the FlowRun row so the entries are available in the run history afterwards. Two kinds of log calls exist:
  • Event logs are written by nodes to describe what is happening in the run. These appear in the editor’s run view and in the FlowRun’s recorded log. Internal detail and identifiers are fine here.
  • System logs are routed to Twine’s internal logging infrastructure. These are subject to different retention and must not include personally identifiable information at info or above.
For debugging a specific flow, the event log is what operators look at first.

​
Trace identifiers

Every run gets a unique trace identifier at the moment it starts. The trace ID is attached to every log entry the run emits and to any internal observability signals routed out of the run. Trace IDs are the connection between a failing run in the UI and whatever diagnostic tooling captured the underlying failure.

​
Retention

Run history is retained per flow. Older FlowRun rows and their logs are eventually pruned; the exact retention window depends on the flow’s configuration and the surrounding system settings. For long-term auditing of data that flowed through a run, rely on the target systems’ own records rather than the FlowRun log.