Operational Metrics

Because Wishfleet tracks sequential processes, timestamps every state change, and records reasons for every closure, a full set of operational metrics is derivable from the workflow data model. No separate analytics pipeline, no event-stream instrumentation, no BI team required to stand up basic visibility.

What's available

Per-stage and full-funnel conversion

What percentage of instances entering each process advance to the next, and the end-to-end completion rate across the full workflow.

Example query shape against the workflow tables:

SELECT
  p.info->>'name' AS process,
  COUNT(*) AS entered,
  COUNT(*) FILTER (
    WHERE p.info->>'status' = 'closed'
      AND p.info->>'reason' = 'success'
  ) AS advanced
FROM "WorkflowNode" p
WHERE p.type = 'process'
GROUP BY p.info->>'name';

Dwell time

Average and percentile time spent in each process — including time in individual goals and tasks. Derived from process node timestamps — the time between process creation and completion.

SELECT
  p.info->>'name' AS process,
  AVG(p."updatedAt" - p."createdAt") AS avg_dwell,
  PERCENTILE_CONT(0.5) WITHIN GROUP (
    ORDER BY p."updatedAt" - p."createdAt"
  ) AS median_dwell
FROM "WorkflowNode" p
WHERE p.type = 'process'
  AND p.info->>'status' = 'closed'
GROUP BY p.info->>'name';

Work-in-progress depth

Real-time count of instances at each stage. A snapshot of how many units, loans, or underwriting cases are currently in each stage. Uses the durable stage pointer (stageName, stageId, stageIndex) on the workflow root — monotonically forward-advanced and never cleared.

SELECT
  info->>'stageName' AS stage,
  COUNT(*) AS wip
FROM "WorkflowNode"
WHERE type = 'workflow'
  AND info->>'status' = 'open'
GROUP BY info->>'stageName';

Throughput

Instances completing per unit time, by process and overall.

Error disposition

For closures that did not reach the terminal success state, the breakdown of reasons per process. Shows where workflows stall and why.

SELECT
  info->>'stageName' AS last_stage,
  info->>'reason' AS closure_reason,
  COUNT(*) AS count
FROM "WorkflowNode"
WHERE type = 'workflow'
  AND info->>'status' = 'closed'
  AND info->>'reason' != 'success'
GROUP BY info->>'stageName', info->>'reason'
ORDER BY count DESC;

Time-to-evidence

How long after entering a process the required evidence typically arrives. Derived from node timestamps and evidence attachment records.

Exception and recovery rates

How often instances enter blocked states, how often they recover, and the recovery paths used. Derived from goal and task status changes into and out of exception states.

How to use these metrics

Direct query

Query workflow data via the REST API. The getWorkflowState endpoint returns the full node tree of an instance — workflows, processes, goals, tasks, and their statuses — useful for per-instance operational views. For aggregate queries across instances, use the metrics endpoints or export to your BI stack.

Feed into BI

Export the workflow tables to your existing analytics stack. The data model is relational and well-structured — standard ETL patterns apply. Timestamps are on every row; the info JSON column carries domain-specific attributes.

Packaged metrics API

The packaged metrics API provides pre-built metric computations, time-series aggregation, and dashboard-ready endpoints over the workflow data.

What's next