Search run history
Easy to filter runs by status or full-text search by data values they processed.
How important run history is for automations?
WEXTL® records every workflow run step by step - detailed info with status, trigger event, credits spent, and the exact input and output of each node [2]. Run history can be opened in right sidebar on the workflow builder page [1]. Use its insights to debug workflows on the same canvas you built them.
Run history data is visible to the whole team. Using it with Analytics feature [5] it becomes easy to track how much credits account uses per day. Combined with Audit log [6] WEXTL gives you important information who changed a workflow before it run.
- GDPR
- Data Encryption
- 2FA
- Local Data Region
Video slide shows the Runs sidebar listing recent workflow executions with status badges on WEXTL®.
How typically run history is used for workflow maintenance?
Built for the moment something breaks or not clear - to search and trace runs that are performing not as expected. Here are 4 ways how our customers rely on [3] run history data in their automations.
Trace run step by step
Scheduled and webhook runs leave the same trail - confirm what fired and when.
Explore node data
Inputs and outputs are visible on the node that produced them.
Cross team view
Anyone from the team can view automation runs - no more screenshots in chat.
How to find why a workflow run failed?
There are only 3 steps between a red status badge and a fixed automation. Most failures are found and rerun in a few minutes [3] - without leaving the workflow builder [1].
STEP 1
A trigger fires and the run opens
A Webhook hit, a scheduled tick [8], or a manual Run once each open a run entry the moment they start. Trigger type and start time are visible before the first node finishes.
Runs
Webhookjust now
Schedule09:00
Run once2 h ago
STEP 2
Every node saves its data
Each node stores its input and output as it completes - an app response, a JS Code return value, an AI Agent tool call [7]. You get a step-by-step record, not just pass or fail.
STEP 3
Open the failed node, fix, rerun
Click the red node to read the payload it received and the error it produced. Adjust the workflow on the same canvas and rerun - the failed run stays in history for comparison.
JS Code
Input
{ "order": "SKU-88421", "email": null }
Cannot read properties of null (reading 'split')
How to spot runs that need attention?
Every run lands in the Runs sidebar with a status chip - succeeded, failed, or needs attention - plus relative time and the credits it spent. Filter to needs attention and you land on the one run that stalled, instead of scrolling past thirty successful ones [3].
The credit chip on each run is where a spike on the Analytics [5] chart gets its answer. Analytics tells you which day the org burned more than usual; the run history of that workflow tells you which run did it and why.
A scheduled tick [8] and a Webhook run leave the same kind of record. So when someone asks "did the Monday report actually send?", you open the run - not the Audit log [6], which tracks who edited the schedule, not what the workflow did.
Video shows Runs list filters with needs-attention and status chips on WEXTL®.
Can I search runs by what was inside them?
Yes. Full-text search [4] matches the data that moved through the workflow - an order number, an email address, a message body - not only the run ID. Search "SKU-88421" and you land on the one run out of thousands that carried it.
Every node keeps its own data inside the run. A JS Code return value, a Webhook payload, the arguments an AI Agent [7] sent to a tool - each sits on the exact node that produced it, on the canvas you built [1].
According to WEXTL® internal data [3], the most common fix path is: find the run by payload, open the failed node, correct the mapping, rerun. No request IDs to match across two dashboards.
How full-text search finds a run by its payload content on WEXTL®.
Supported integrations
Frequently asked questions
Run history shows what one execution did - which nodes ran and what data moved. The Audit log (Dashboard → Activity) shows org-level changes - who edited a workflow, rotated a credential, or removed a member. "Did the digest send?" is a run history question; "who moved it to 8am?" is an Audit log question.
Analytics plots org-wide usage per day across the billing cycle. Run history shows each single execution and the credits it spent. Use Analytics to find the day usage jumped, then open run history to find the run behind it.
Run data is kept for the retention window of your plan - see the pricing page for days per plan. Runs older than that window are removed in full, including their payloads.
Full-text search over payload content is included on plans that list it. Every plan can still filter runs by status and open any run by date or trigger type.
No. The failed run stays with its original error and payload, and the rerun creates a new entry - so you can compare the two side by side.
Debug with a real trail or explore more
References
Explore list of resources that helped WEXTL® team to craft this page. Use a citation marks to jump directly to the source.
- WEXTL® visual workflow builder — canvas for building and visually tracing automations.
- WEXTL® built-in workflow nodes — catalog of built-in nodes with per-node documentation pages.
- WEXTL® anonymized usage experience from customers — collected by support team and/or partners.
- WEXTL® pricing plans — per-plan entitlements — limits, quotas, and included features.
- WEXTL® Analytics — credits, data transfer, and AI usage per day across the billing cycle.
- WEXTL® Audit log — organization Activity feed - who changed what, and when.
- WEXTL® AI Agent — node documentation.
- WEXTL® Workflow Scheduler
- WEXTL® Apps Library — full catalog of supported app integrations.