Logs
Every workflow run is recorded — whether you started it yourself, a schedule fired it, a webhook arrived, someone sent a form, or it was launched from a chat. The Logs tab is where you read those runs back: which workflow ran, how it ended, how long it took, and — one click deeper — exactly what every single step received and produced.
This is the page you open when something didn't happen the way you expected.
:::info What you see depends on who you are People with the Admin or Executive role see the runs of every workflow in the organization, not just the ones they started. Everyone else who has access to Workflows sees only their own runs — plus, when they may read the shared folder, the runs that a Shared Folder Trigger started on their own workflows. :::
Opening Logs
Go to Workflows → Logs.
If you have permission to see import and export activity, a small switch at the top offers two views:
| View | What it lists |
|---|---|
| Runs | What the workflows did — every run, with its status, trigger and duration. This is the view you land on |
| Activity | What people did to the workflows — who exported or imported one, and when. See Activity |
Without that permission there is no switch, and the tab shows the runs directly.
The Runs view has three parts:
- A row of filters on the left and a Refresh button on the right.
- The runs table.
- Previous / Next paging under the table, when there is more than one page of runs.
The runs table
Each run is one row.
| Column | What it shows |
|---|---|
| Workflow | The workflow that ran |
| Status | How the run ended, or where it is right now |
| Trigger | How the run started |
| Started | The date and time it began, in your local time |
| Duration | How long it took |
| (last column) | A Resume button, on a paused run you may continue — see Resuming a paused run |
A few things the table does on its own:
- Failed and cancelled runs get a faint red tint, so problem runs stand out while you scroll.
- A run whose workflow was deleted shows (deleted) in the Workflow column. The run stays in the history as a record, but it can't be opened — clicking it tells you "This run's workflow was deleted — no execution detail."
- Click any other row to open the full run detail.
Run statuses
| Status | What it means |
|---|---|
| Queued | Accepted and waiting to start |
| Running | In progress right now (the badge pulses) |
| Completed | Finished successfully |
| Failed | Stopped because a step hit an error |
| Cancelled | Stopped before it finished |
| Paused | Waiting on something before it can continue — a connection that needs attention, or a person |
When a paused run is waiting for a person, a short line under the badge says so: "Waits for the person filling in the form" or "Waiting for approval".
Resuming a paused run
A run that paused because a connection needed attention can be continued once the connection is fixed.
- Fix the connection on the Connections tab.
- Come back to Logs, find the Paused run, and click Resume at the end of its row.
- You see "Resuming the run…". Click Refresh after a moment to watch the status change.
| Who sees the Resume button | Notes |
|---|---|
| The person whose run it is | Whoever started it — or, for an automatic trigger, the person the run belongs to |
| People with the Admin or Executive role | For any run in the organization |
Runs that wait for a person have no Resume button: only the form answer or the approval decision continues them. See Forms and Approvals.
:::caution A long pause can cost the run its files If a resume is refused you see "Could not resume the run — if it was paused for a long time its files may already be gone." The files a run works with are temporary. Start the workflow again instead. :::
A run you started in the editor during this visit can also be resumed there, from the Logs dock — see Running Workflows. The Resume button here works for every paused run, including ones started by a schedule or a webhook.
How the run started
A pill in the Trigger column tells you where the run came from.
| Trigger | The run was started by |
|---|---|
| Manual | Someone clicking Run in the workflow editor, or Re-run here |
| Webhook | An outside service calling the workflow's webhook address — including Telegram, Slack and WhatsApp triggers |
| New mail arriving for a Gmail, Outlook or IMAP trigger | |
| Schedule | A recurring schedule reaching its next occurrence |
| Chat | A conversation with an AI assistant, after the user approved it |
| Form | Someone sending a workflow form |
| Folder | A file arriving in a watched folder of the shared folder |
| API | A call to the workflow's API trigger |
| Test | A trigger test from the editor — "Listen for a test event" or "Fetch the latest email". It ran the saved draft, not the published version |
| Error workflow | Another workflow failing, with this one set as its error workflow |
This column is often the fastest answer to "why did this run at 3 a.m.?" — see Schedules for recurring runs and Running Workflows for the other ways a workflow starts.
Narrowing the list
Three dropdowns sit above the table. They work together — set as many as you like.
| Filter | Choices |
|---|---|
| All workflows | Any single workflow you can see |
| All statuses | Completed · Failed · Running · Queued · Paused · Cancelled |
| All triggers | Manual · Webhook · Email · Schedule · Chat · Form · Folder · API · Test · Error workflow |
Changing any filter takes you back to the first page of results.
Click Refresh to pull in the newest runs without reloading the page. This is useful while a run is still going: refresh and watch Running turn into Completed or Failed.
:::tip The fastest triage Set All statuses to Failed and leave everything else alone. What's left is your entire problem list, newest work included. :::
Paging through runs
Runs are listed 30 to a page. When there are more, Previous and Next appear under the table with a counter between them showing which slice you're looking at and how many runs matched in total — for example 31–60 / 214.
Previous is greyed out on the first page, and Next is greyed out once you reach the end.
When the table is empty
The message tells you why it's empty, so you know whether to worry.
| What you see | What it means | What to do |
|---|---|---|
| No runs yet — "Runs appear here once you execute a workflow, attach a schedule, or trigger a webhook." | Nothing has ever run | Run a workflow, or give it a schedule or webhook |
| No runs match this filter | Runs exist, but not with the filters you set | Click Clear filters to reset all three dropdowns |
| Could not load logs. | The list couldn't be fetched | Click Try Again |
Inspecting a run
Click a run and a full-screen inspector opens over the page. This is the detailed, step-by-step record of that one run.
Close it with the ×, by pressing Esc, or by clicking the dimmed area outside it.
The top bar
Left to right:
| Item | What it does |
|---|---|
| Workflow name | The workflow this run belongs to |
| Status | A coloured dot plus the status word |
| Trigger pill | How this run started |
| Run id | A short id — click it to copy the full one, handy when you need to point someone at this exact run |
| Re-run | Starts the workflow again from the beginning. A toast confirms "Workflow re-run started" |
| ↑ / ↓ | Jump to the previous or next run in the list without closing the inspector |
| × | Close |
:::caution What Re-run does — and doesn't Re-run starts a new manual run of the workflow's latest saved state. It does not carry over the data the original run started with — a webhook body, a form answer, an email. For a workflow that depends on that data, trigger it again from its source, or run it from the editor with test values.
The inspector has no stop button either. To stop a run that's still going, use the Logs dock in the workflow editor — see Running Workflows. :::
The metric strip
A thin line under the top bar summarises the run at a glance:
- Started — the date and time it began
- Duration — how long the whole run took
- {n} blocks — how many steps were recorded
- Failed at {step name} — shown in red, only when the run failed
That last one usually answers your question before you read anything else.
The timeline
Under the metric strip is a single band showing the run as a waterfall. Each step is a coloured segment: its position is when the step started, its width is how long it took.
- Steps that ran one after another read as a left-to-right chain.
- Steps that ran at the same time (inside a Parallel block) overlap.
- Failed segments are red and carry an exclamation marker.
- Hover a segment to see the step's name and how many milliseconds it took; click it to select that step below.
If the run has no timing information you'll see "No timing data for this run" instead of the band.
The step list
The left pane is the run's trace, top to bottom, in the order things happened.
Each row shows the step's icon, a status icon, its name, and a short result line:
| Result line | Meaning |
|---|---|
| Success in 142ms | The step finished cleanly, with how long it took |
| Failed in 1.2s | The step errored — the row is red |
| Running… | Still in progress |
| Pending | Recorded but not started yet |
| Waiting for a response · 12 min | The step handed the run to a person — a form page or an approval — and has been waiting that long |
Loops and parallel branches nest: the container is one row with a chevron, and its iterations sit underneath. Click the container to fold or unfold it; click a single step to inspect it on the right.
:::tip A failed run opens on the failure When you open a run that failed, the first failed step is selected for you automatically — you land on "what broke" without hunting for it. :::
If nothing was recorded, the pane reads "No steps recorded for this run."
Drag the divider between the two panes to give the step list more or less room. On a narrow screen the panes stack instead, with the step list on top.
Input and output
The right pane shows the selected step's Input on top and its Output below. Until you pick a step it reads "Select a node to inspect its input and output".
- Input is everything that flowed into the step — the values its fields resolved to at that moment.
- Output is what the step produced, which is exactly what later steps read through references like
<agent.content>.
How the values are shown depends on what they are:
- Text results from AI steps render as formatted text, with small chips for the model used and the tokens spent. A Structured output link underneath opens the same result as a data tree.
- Everything else renders as an expandable tree. Top-level entries are open; nested ones start folded, so a large result stays readable. Each value carries a small type label (string, number, boolean, array, object).
If a step ran several times — a loop iteration or a parallel branch — a selector appears above the panes so you can page between the individual runs of that same step.
:::note Secrets never appear here
Sensitive values in a step's input are hidden in the record and show as [redacted]. A hidden value is not a missing value — the step received the real one.
:::
Steps whose data you can't see
A run started by an automatic trigger works with the permissions of the person who published the workflow. When you open such a run and it isn't yours, some steps show this note instead of their input and output:
"This step ran with the permissions of the person who published the workflow; only they and administrators can see its input and output."
You still see the step's name, status, timing and error. Ask the publisher or an administrator if you need the data itself.
Files a run produced
When a step read or created a file, the file appears in its input or output as a small chip with the file's name and size and a note on how long it is kept:
| Note on the chip | What it means |
|---|---|
| "belongs to this run, removed when the run ends" | A temporary file. It exists only while the run is going |
| "kept for the form's retention period, deleted on …" | A file someone sent with a form. It is kept as long as that form keeps its responses |
| "retention period ended, deleted" | The form's retention period is over and the file is gone |
If you are allowed to download run files, the chip also carries a Download button. Files sent with a form can be downloaded only by the person the run belongs to, or by someone your organization has given that permission. If the file is already gone you see "Could not download the file — if the run has ended it may already be gone."
When a step failed
Select a failed step and a red error card appears above its Input.
The card leads with the error message in plain text, then adds whatever is known about the failure:
| Part of the card | What it tells you |
|---|---|
| Tags under the message | The kind of problem, an HTTP status if the step was calling a service, an error code, a Retryable flag when the same call is worth trying again, and the reason an AI step stopped |
| Rejected input | When a step refused the data it was given — for example a table row — each field that was refused and why: the wrong type, a required value that was missing, a column that doesn't exist, a value that is too long |
| Blocked addresses | When the step tried to reach an outside address that isn't allowed: the list of refused addresses, and a reminder that an administrator can allow them under Workflows → Packages — see Packages |
| Details from {step name} | The step's type and id, its status, how long it ran before failing, when it started, and which iteration failed when it was inside a loop |
| On error | Whether the failure was Routed to the error branch (your workflow handled it) or Halted the run (it stopped there) |
| Copy as JSON | Copies the whole error record to your clipboard, ready to paste to whoever can help |
Directly under the card you get the Input that produced the failure — which is almost always where the real answer is.
:::tip Most run problems are data problems Steps rarely break on their own. Far more often a reference is pointing at a value that isn't there — a field name spelled differently, an empty result from the step before, a trigger that didn't carry the field you expected. Compare the failed step's Input with the previous step's Output and the mismatch usually jumps out. :::
Activity: who exported or imported
The Activity view lists every time a workflow was taken out of Arketic as a file, or brought in from one. It is shown only to people who have permission to see it; by default that is Admins.
| Column | What it shows |
|---|---|
| Who | The person's name, with their email underneath. "Deleted user" if the account no longer exists |
| Action | Exported or Imported |
| Workflow | The workflow's name as it was at that moment, and how many blocks the file held |
| When | The date and time |
| IP | The network address the action came from |
The list is newest first, 30 to a page, with Previous and Next and a counter such as 1–30 of 64. Before anything has been exported or imported it reads No imports or exports yet — "Every workflow file downloaded or brought in is recorded here."
The name is plain text, not a link: the record is kept even if the workflow was renamed or deleted afterwards. For how exporting and importing work, see Importing and Exporting.
Working through a failed run
A repeatable routine:
- Open Workflows → Logs and set the status filter to Failed.
- Click the run. It opens on the step that failed.
- Read the error card — the message and its tags say whether this is a data problem, a permission problem, or an outside service having a bad day.
- Look at that step's Input. Is every value what you expected? Anything empty or missing?
- If a value is wrong, walk one step back in the list and read its Output — that's where the value came from.
- Fix the workflow (a reference, a field, a connection) and save it.
- Run it again from the editor — or press Re-run here, if the workflow doesn't depend on the data its trigger delivered.
:::caution If the error mentions a connection A run that fails or pauses because a key was rejected or expired needs the connection fixed, not the workflow. Sort it out on the Connections tab, then resume the paused run or run again. :::
Tips
- Check Logs after every change. One run through the editor plus one read of the trace is the fastest way to confirm an edit does what you meant.
- Use the run id. Copy it from the top bar when you report a problem — it points at one exact run.
- Use ↑ / ↓ to compare. Two runs of the same workflow, one good and one bad, read side by side are a very quick diagnosis.
- Watch the timeline for slow steps. A single wide segment is where your run is spending its time.
- Filter by trigger when a workflow runs on both a schedule and a webhook and only one of them misbehaves.
Related pages
- Running Workflows — starting runs, stopping them, what a paused run waits for
- Schedules — recurring runs and why one may not have fired
- Connections — fixing a rejected or expired connection
- Blocks — what each step does and what it outputs
- Creating Workflows — building and editing the workflow itself
- Workflows Overview — the Workflows tabs at a glance