Execution history
Status, duration, execution ID, and the trigger source: user, schedule, agent, or listener. Every run has a shareable URL, and retries are marked as retries rather than hidden as separate runs.
Visibility and traceability
A green run tells you almost nothing.
What ran, what it found, what it cost, and who changed it. Filter any of it in the UI, or pull the same data from the API, the CLI, or an MCP client. Or just ask the agent.
Three questions, three layers
- Did it run Execution history Status, duration, trigger source, logs, retries
- Is it healthy Findings, heatmap, incidents Drift, slow steps, resource breaches, schedule collisions
- Who touched it Audit trail User, method, result, IP, full payload
Most platforms answer the first question and stop. The second is what costs money, and the third is what a security review actually asks for.
Capabilities
What’s built in.
Flow Findings
A static analyser that walks the whole flow, nested sub-flows included, against dozens of known patterns: batch processing off, shapes that will not scale. Each finding carries a severity, why it matters, and a fix, before the flow has ever run.
Executions heatmap
Activity by hour, day, week, or month with intensity by volume. Average executions, records processed, average duration, and your peak window. Click a cell to open the runs behind it.
Scheduled activity
Expected Timeline simulates upcoming runs from your schedules. Gaps finds the windows with nothing in them. Scheduled vs Actual shows the drift between what you planned and what the scheduler actually did.
Resource utilisation
CPU, RAM, JVM heap, threads, disk, and open file descriptors, per cluster node. Top flows by estimated resource consumption answers “which flow is doing this to us” with a confidence level on the estimate.
Incidents that open themselves
When CPU, RAM, or disk breaches a threshold and stays there for a sustain window, an incident opens with a severity and a trigger value, and closes when it settles. Brief spikes do not wake anyone.
Audit trail
Every important system event: running a flow, editing a connection, adding a user, changing configuration. Each records the date, method, user, tenant, result, duration, and both the client and host IP.
Filter it, then follow it
Server-side filters on date, status, method, user, duration, client IP, exception text, and inside the event payload. Open the full JSON, jump to the object the event touched, or read the stack trace behind a failure.
Over the API, and over MCP
The same events come back from the built-in API with JWT auth, filtered by type, user, and timestamp. The MCP server hands the same tools to Cursor or Claude Desktop, with exposure controlled per tool.
All of it from the CLI
The built-in CLI queries the same data with a select, a where, and an order by. flow-executions, get-audit-records, metrics, get-flow-status, and tail-flow-log run against one tenant or across all of them.
Or just ask Simba
Simba, the agent built into Etlworks, reads execution history, logs, configuration, and findings, then answers in a sentence. Which flows failed overnight, what changed on that connection, which one is eating the CPU.
AI usage and spend
Tokens split by prompt and completion, agentic against non-agentic, conversations and requests, with billable and non-billable cost, wallet balance, monthly drain, and cap. Tenants on their own provider key show zero billable.
Specifications
What an audit event records.
Every important system event is captured: flow runs, connection edits, user changes, configuration changes, and every field below is filterable server-side, including free-text search inside the payload.
Every event carries
Date
Timestamp, shown in your browser’s timezone; filters are UTC
Method
The operation:
runFlow, addFlow, editConnection, and the restUser
Who performed it
Tenant
Which tenant it happened under, on the main account
Result
Success or Error, with the full stack trace behind a failure
Duration
How long the operation took, filterable by threshold
Client IP / Host IP
Where the request came from and which host served it
Payload
The complete JSON, including IDs, log UUIDs, flow names, and event types
Who sees what
Tenant Admin
Sees audit events for their own tenant
Super Admin
Sees every event across all tenants, and can switch Insights into aggregated multi-tenant mode with a per-tenant breakdown behind each number
Findings retention
Configurable from one to thirty-six months
FAQ
Common questions.
Who can see the audit trail?
Admins, scoped to their tenant. In a multi-tenant deployment a Super Admin sees events across every tenant while a Tenant Admin sees only their own. That boundary is the same one the rest of the product enforces, not a separate rule for logging.
Can I answer “who changed this connection?”
That is what the trail is for. Filter by method, user, or date, search inside the event payload for a flow name or ID, then click through to the object the event touched. Failures open their full stack trace.
Do I have to go looking for problems?
Not for the common ones. Every run writes a Flow Findings report on its own, covering schema drift, slow steps, recurrent errors, and data-quality concerns, each with a severity and a recommended action. Resource incidents open and close themselves against thresholds you set.
Can I get this out of the UI and into our own tooling?
Yes. The audit trail is available through the built-in API with JWT authentication, filtered by type, user, and timestamp. Execution history and results are reachable the same way.
How long is any of this kept?
Findings retention is configurable from one to thirty-six months. Reports survive the deletion of the flow that produced them, so a decommissioned pipeline still has a history.
Is this the same as the security controls?
It is the evidence layer underneath them. Access control decides what someone may do; the audit trail records what they did, and admin actions are logged for exactly that reason. The two are designed to be read together.
Start your trial
14 days. No card. Real workloads.
Run a few flows, then open the heatmap and the findings and see what they say about them.