Run journal
The run journal is a log the platform keeps for every execution (run) of a workflow. It answers “what happened in this run?” without you having to draw anything for it: what started the run, what the AI was asked and answered, what the bot said, what the user pressed, and what went wrong.
What is recorded
Section titled “What is recorded”Most entries are written automatically — you don’t add icons for them and can’t switch them off:
- Trigger — the event that started the run (for example the incoming Telegram message or webhook payload).
AI — every call to an AI model: the prompt, the answer (or the option a choice node picked), the model that was used and the token usage.
Message — what the scenario sent out: Telegram messages and files, and the questions it asked with their buttons.
User input — an accepted answer (a button pressed, a task resolved), or a timeout when nobody answered in time.
Warnings and errors — input the scenario ignored (for example a press on an old, already answered button), a step that failed (every failed attempt is listed, also the ones that were retried successfully afterwards), a run that ended with an error, and input that could not be delivered to the run at all.
Log — what you write yourself with the log icon. Its text goes into the journal as an ordinary Info entry attached to that icon (the log icon has no levels).
Only the built-in integrations are described this way. Actions from the ActivePieces catalog are not journaled while they work, but if one of them fails, the failed attempt appears as an error entry like any other step’s failure.
Where to see it
Section titled “Where to see it”Project → Runs, then open a run: the details drawer opens on the Journal tab (the default). The other tabs hold Input & result and the engine’s own Temporal events.
Each row shows the time, the kind, the level and the icon that produced the entry; click the icon’s name to open its document and highlight it on the canvas. Expand a row to see the details — the prompt and answer as text, the rest as JSON.
Filter by Kinds and Level, or switch on Errors only to see just what went wrong.
For a chat bot, Whole conversation shows the journal of all runs in that chat together (every Telegram chat is one conversation, continued by new runs over time); This run only switches back.
When you press Run in the editor, the live side panel shows the same journal as it grows.
Entries are written in the background so they never slow a run down — they appear a second or two after the event happens. The journal also outlives the engine’s own run history: a run that the engine has already forgotten can still be read from its journal.
How long it is kept
Section titled “How long it is kept”Entries are deleted after 14 days, separately counted for dev-stand and published (prod) runs. A project’s
entries are deleted together with the project. If you run Falang yourself, set
RUN_JOURNAL_RETENTION_DAYS_DEV and RUN_JOURNAL_RETENTION_DAYS_PROD on the backend to change
the number of days (both default to 14).
Don’t store texts
Section titled “Don’t store texts”A journal can contain what your customers wrote and what the AI answered. To keep that out of it, open Project → Run journal and switch off Store texts (prompts, answers, messages). From then on new entries keep only metadata — kind, icon, model, sizes, error type — and are marked “texts not stored”. Error messages are kept, shortened. Entries that were already stored are not rewritten; they simply expire with the retention period.
Very long texts are cut to a reasonable size in any case (marked “truncated”), and files are recorded as references, never as content.