Visibility and traceability

A green run tells you almost nothing.

What ran, what it found, what it cost, and who changed it — in one place, filterable, and available over the API. Run history is the floor here, not the ceiling.

Start free trial Talk to us

Three questions, three layers

  1. Did it run Execution history Status, duration, trigger source, logs, retries
  2. Is it healthy Findings, heatmap, incidents Drift, slow steps, resource breaches, schedule collisions
  3. 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.

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.

Flow Findings

Every run writes an inspection report: schema drift, slow steps, recurrent errors, data-quality concerns. Each carries a severity from ALL_GOOD to CRITICAL and says what to do about it. Reports outlive the flows that produced them.

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 plan and reality.

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. Date, method, user, tenant, result, duration, and both client and host IP.

Filter it, then follow it

Server-side filters on date, time, status, method, user, duration, client IP, exception text, and inside the event payload. Open the full JSON, jump straight to the object the event touched, or read the stack trace behind a failure.

Audit trail over API

The same events are available programmatically through the built-in API with JWT auth, filtered by type, user, and timestamp, for shipping into whatever you already use for security review.

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 rest
User
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.

Start free trial Talk to us