Monitor workflows with analytics
Use the Analytics page to track run counts, failure rates, latency, and resource consumption across your workflows.
| Workflow Analytics Availability | |||
|---|---|---|---|
| Cloud | Closed beta | ||
| Self-hosted Edge Expected in 3.387.0 and later | Closed beta | ||
Use the Analytics page to monitor workflow health and activity across your organization. You can review aggregate stats across all workflows or drill into a single workflow to investigate failures, latency, and resource usage.
To open Analytics, go to the workflows landing page and select Analytics. The left sidebar lists every workflow in your organization. Use the search box to filter workflows by name.
All workflows
The default view shows aggregate activity across every workflow in your organization. Use it to understand overall traffic, surface reliability issues, and identify which workflows consume the most resources.
Summary stats
The top of the page shows three summary metrics for the selected time window:
- Total runs: All runs across every workflow, including successful and failed.
- Failed runs: Runs that ended in an error or were terminated.
- Failure rate: Failed runs as a percentage of total runs.
Use these to get a quick read on overall workflow health before drilling into specifics.
Most frequent workflows
The Most frequent workflows table ranks workflows by total run count over the selected time window (the default is 30 days). Use it to understand traffic patterns and identify workflows with unexpectedly high run counts.
Top problem workflows
Top problem workflows highlights workflows that have run at least five times with a failure rate of 10% or higher over the selected time window (the default is 7 days). Use it to find workflows that need attention.
The Common failing block column shows which block type failed most often, which helps narrow down the cause:
- A specific block type as the most-common failing block usually points to a logic issue in that block.
- Failures concentrated during high-traffic periods usually point to a capacity issue.
- On self-hosted instances, many
THROTTLEDruns across multiple workflows usually point to insufficient code-executor pod capacity. Refer to the Best practices page for more information.
To investigate a specific workflow, click its name to open the individual workflow view.
Top resource consumption
Top resource consumption shows total data volume processed by each workflow for the current calendar month. Use it to identify workflows that move large payloads in or out of your data sources.
- Cloud
- Self-hosted
Resource usage stats (memory and CPU) are not available on cloud. Refer to Workflow limits for the fixed memory and CPU caps that apply to cloud workflow runs.
The section also includes memory and CPU aggregated per workflow. Use the Max memory (MiB) and Max CPU (vcores) columns to right-size your code-executor deployment:
- Review the current organization-level and workflow-level limits. Refer to Workflow limits for the defaults.
- Set default limits 20–30% above observed peaks.
- For workflows with very different profiles, configure per-workflow overrides instead of raising the global default.
Individual workflow
Click any workflow in the left sidebar, or from one of the tables in the all workflows view to open its detail view. All metrics are scoped to that workflow and the selected time window.
Summary stats
Four summary stats appear at the top of the detail view:
- Total runs: All runs for this workflow in the selected window.
- Success rate: Successful runs as a percentage of total runs.
- Failure rate: Failed runs as a percentage of total runs.
- Avg latency: Mean run duration across all runs.
Run breakdown
The Run breakdown chart shows run volume over time, broken down by status (successful, failed, throttled). Use it to spot spikes in failures or traffic.
Latency breakdown
The Latency chart shows run duration over time. Use it to identify performance regressions or runs that are taking longer than expected.
Resource consumption
The Resource consumption chart shows total input and output data volume for this workflow for the current calendar month.
- Cloud
- Self-hosted
Memory and CPU usage stats are not available on cloud. Refer to Workflow limits for the fixed limits that apply.
Also shows average and peak memory and CPU for this workflow. Use it alongside the latency breakdown to determine whether a slow or failing workflow is hitting resource limits.
Recent runs
Recent runs contains a paginated list of individual runs for this workflow. Additional pages load automatically as you scroll.
| Column | Description |
|---|---|
| Run ID | Unique identifier for the run. |
| Status | Outcome of the run. Refer to Run statuses below. |
| Created at | When the run was queued. |
| Completed at | When the run finished, was throttled, or was terminated. |
| Duration | Elapsed time in seconds. |
Run statuses
The following workflow run statuses are available:
| Status | Meaning |
|---|---|
SUCCESS | The run completed without error. |
FAILURE | The run encountered an error during execution. |
THROTTLED | The run was rate-limited and rejected. Retool retries it automatically. |
PENDING | The run is queued waiting for a concurrent slot. |
IN_PROGRESS | The run is currently executing. |
For log entries and per-block details, refer to Workflow run logs.
Data freshness and retention
Analytics data is aggregated hourly. New runs can take up to one hour to appear in aggregate views. Recent runs updates in near real time.
| View | Default range | Maximum range |
|---|---|---|
| Most frequent workflows | 30 days | 30 days |
| Top problem workflows | 7 days | 30 days |
| Top resource consumption | Current month | Current month |
| Recent runs | 14 days | 30 days |
For run-level retention, refer to Workflow run logs.