SynapseOrch 2.0 is a release candidate; the stable release is 1.9.3. How to try 2.0

Runs and Logs

Every run is kept: find it on Runs, read its path step by step with each step's output, time and cost, answer it on its page when it waits for you, see why one failed, and read the full transcript of what each model was sent and answered.

Runs

Runs lists every workflow run, newest first and grouped by day, including the ones a schedule or the API started: each run's workflow, the path of its steps, how long it took, its cost and start time, and under the name its status (Running · Draft reply, Needs input · Approve payment, Failed · Fetch orders). Pick All, Needs you, Running, Queued, Failed, Completed or Cancelled at the top to show only those, and Search runs… to find one by its workflow, its run ID, its trigger, a step or its status. A row opens the run's page. Its tabs are Runs, Logs, Evals and Usage.

A run whose workflow was deleted since stays in the list, named Deleted workflow, and its page opens from the copy of the workflow the run kept.

A run's page

A completed Specials board run's page: its status, time, steps, tokens and model cost, the result, its two steps on the path's timeline, what it produced, and its activity.

The page is named after the workflow, with the run's ID under it, and Open in editor; Cancel while it runs or waits in line, and Replay once it failed or was cancelled. Under the name: its status (Queued, Running, Needs input, Completed, Failed or Cancelled), when it started, its wall-clock time, its steps (3 of 5 steps done), its tokens and its model cost, with the workflow's cap on a run when it has one. While it runs these read so far.

Below them, in order:

  • The result of a completed run, with Copy and the step it came from. A run that did not complete says why instead, in a card at the top — what happened, what to do about it (Replay, Model settings, Raise the cap, Open the calling run, …) and Technical details.
  • Waiting for a person, when the run waits on you: see below.
  • A line saying how the run followed its workflow: Followed the saved workflow: 5 of 5 steps, in order., Stopped at step 3 of 5: Fetch orders., or that the workflow was edited after this run started, when it was.
  • The path: one row per step, with what started the run (Started by: Schedule · Monday digest). Each row shows its type, how long it took, its Cost, and whether it is done, failed, needs input or was not reached; a step that ran again is marked 2nd run. Open a row for what the step did: the models it called, its turns, tokens and the largest prompt it sent, its cost, the tools it used, then its output, or its error. A file it saved reads Saved to the Vault: ….
  • What it produced: each output the run wrote, with the workflow's result marked Result; Open shows one in full.
  • Plan, when an agent set itself tasks: what it set out to do, and how far it got.
  • Activity: the run's events as they happen, Following live while it works, with Jump to latest. While a Browser step or a browser agent works, Live browser shows its page, with Enlarge and Take over; after the run, The browser keeps its screenshots, one per action.
  • Nested runs, for a run that called other workflows: each one's name, status, steps and cost, linking to its page.
  • Shared state: every key the run wrote, as the run left it.
  • Raw event log: every event exactly as the engine emitted it. Self-hosted, Full log is the run's log file: every step, prompt and answer in full. When an answer is wrong, it shows whether the model was given the wrong thing or did the wrong thing with the right one.

Cost

Costs are in dollars (see Usage and cost): $0 for a free model, — where no price is known, <$0.0001 for a tiny one. The run's model cost is the sum of its steps', nested runs included; each step's is on its row and in its opened detail. On SynapseOrch Cloud, the credits a run was charged are shown beside it.

Answering on the page

A run that waits for a person reads Needs input, and its page puts the question at the top, in a card marked Waiting for a person, with the step it waits at and for how long:

  • A question has a box, Type the answer this step is waiting for, and Send answer.
  • A form shows the step's fields, and Send answer.
  • An approval (one yes-or-no field) has two buttons: the field's own label, such as Approve payment, and Decline.
  • A browser hand-over, where a Browser step asks you to do something on the page, has Open the browser, which takes you to Live browser, and Done, which hands it back: You handed the browser back. The run goes on.

Once sent: Answer sent — the run is resuming. A run is answered once: an answer to a run that has moved on is refused. Cancel run stops it instead. The same question can be answered from Home, a channel, Synapse AI or over MCP; see Human gates.

Replay

Replay resumes a failed or cancelled run from the step that stopped, keeping what the steps before it did, on the workflow as it is saved now, so you can fix the workflow and replay. A nested run is replayed through the run that called it: This is a nested run; replay the run that called it, which reruns this step. A run that never reached a step can't be replayed: start it again. A deleted workflow's run can't be replayed either, as there is no saved workflow to run; a deleted workflow's run that waits on a person can still be answered, and carries on with its copy.

Logs

Runs › Logs has the full transcript of each workflow and agent run, chat turns included: what the model was sent, the tools it called with their arguments and results, its answer, and its tokens and cost.

A run that called other workflows lists them under Nested runs, and a nested run's log sits under the run that started it — it is not a separate entry in the runs list. Its cost is part of that run's. A step that failed shows its own reason, in the log and on the step. A nested run is replayed through the run that called it: replaying it alone is refused (This is a nested run; replay the run that called it, which reruns this step.).

A Retrieve step's row says how many passages it found and what it cost — Retrieve · Find clauses: 2 passages · $0.0000 — followed by what it did without, in words, such as Reranking failed; results are in search order. Opening it shows the search's trace: each search's candidates, fusion, rerank, the index version, timings, cost, and each passage with its file. An Ingest step's row says how many records went to which base, and their status.

An Answer a customer question run: the Search the guides step found passages in the compliance guides, and the Answer step wrote a reply citing them.

Scheduled run logs

A schedule's firings are listed on it, under Workflows › Schedules. Each shows:

  • Schedule name and trigger time
  • Actual execution time
  • Run status (completed / failed / cancelled)
  • Duration and cost
  • Link to the full execution log

Where logs are stored

A run's record — its status, timing, state and step history — is a row in the database. The full execution log is an object in blob storage, under each tenant's logs/ prefix:

logs/
├── agent/              # Agent runs
│   └── {run_id}.log
├── orchestration/      # Orchestration runs
│   └── {run_id}.log
└── schedule/           # Scheduled runs
    └── {run_id}.log

On a self-hosted install that is SYNAPSE_BLOB_DIR/default/logs/ — ~/.synapse/var/blobs in an installed SynapseOrch, backend/var/blobs in a source checkout, /data/blobs in the single-container Docker image and /blobs in Docker Compose — or the same prefix in the S3 bucket when one is configured. Read logs through Runs › Logs rather than these files.

Clearing logs

Logs accumulate indefinitely on a self-hosted install — there is no automatic retention policy, so plan for it on anything long-running.

Clear them from Settings → Memory, which deletes stored conversations, embeddings and run history, or delete individual runs from the runs list.

Do not go looking for log files

Earlier versions of this page suggested a find over DATA_DIR/logs. That folder is not used any more — run records are rows in the database and the logs are objects in blob storage — so that command deletes nothing, and deleting log files by hand would leave their records behind. Use Settings → Memory. See Upgrading to 2.0.

On SynapseOrch Cloud

A run's page shows, under its name, its status, when it started, its wall-clock time, its steps, its tokens, the credits it was charged and its model cost; each step's row shows its status, when it ran and its Cost. The wall-clock time counts while the run works; tokens and costs are as of when the page opened, so reload for the latest. The Activity log streams live.

  • A run that did not complete says why in a card at the top. A run that reached its plan's run length says Stopped at the 30-minute run limit of this workspace's plan, after 30.1 min of work.
  • A run waiting for a slot reads Queued, 2nd in line: the workspace's runs at once are all in use, and it starts as soon as one finishes. Its place moves up on its own, time in line is not charged, and Cancel works while it waits. See Capacity.
  • A run waiting on a person reads Waiting for a person, with the step it is waiting at.
  • A run the model wallet stopped says This run stopped because the model wallet ran out., with Add balance.
  • The runs list holds top-level runs only; a nested run is on its parent's page, under Nested runs.
  • A row's menu has Open run, Stop run while it runs, Replay from failed step once it failed or was cancelled, Open workflow and Copy run ID.
  • Replay needs credits, as a new run does: with none left, or a payment past due, it is refused.
  • Logs has the full transcript of each workflow and agent run — what the model was sent, and what it did. There is no schedule log: a scheduled workflow's runs are in the runs list, and a scheduled agent's turns are its conversation in History.

Ninety days after a run ends, its step inputs and outputs are cleared and its record stays; a run past that point cannot be replayed — start it again instead. See Security and data handling.

On this page