Read automation metrics
Open an automation from the Automations list, then select its Metrics tab. Choose the period and available filters before comparing values.
Automations is in Early access. Your workspace permissions determine which actions you can perform.
What the selected period includes
The period selects runs by when they started. A run that starts on Monday and finishes on Wednesday updates Monday's results. Long waits can therefore change an earlier period after that period ends.
Metrics describe real runs. Draft previews create no run and contribute nothing to the totals. Trigger-filter misses, skipped schedule ticks, and overlap skips also create no run.
Read counts and rates
| Measure | Meaning |
|---|---|
| Started | Runs admitted during the selected period. |
| In progress | Queued, running, and waiting runs that started in that period. This is not a count of every active run in the workspace. |
| Succeeded, failed, canceled | Runs from the selected period that reached each terminal state. |
| Completion rate | Succeeded, failed, and canceled runs divided by started runs. |
| Success rate | Succeeded runs divided by succeeded plus failed runs. Canceled and unfinished runs are excluded. |
| Elapsed duration | Time from a run being admitted to its ending, including queue time and waits. |
A rate without an applicable denominator is unavailable. It should not be read as zero percent.
Failure rate is failed runs divided by succeeded plus failed runs. Canceled and unfinished runs are excluded.
A reminder that deliberately waits two days can have two days of elapsed duration even when its messaging step runs quickly. Inspect an individual run before treating duration as a processing problem.
Typical elapsed time · p50 is the median duration: half of measured completed runs finish within that time. Long-tail elapsed time · p95 is the duration within which 95% finish. These values include intentional waits.
Distinguish workflow outcomes from delivery
A workflow can succeed after handling a failed lookup or deciding not to send. A successful send step means acceptance by the channel. Neither result establishes message delivery or a customer conversion.
Outcome reasons come from configured Exit nodes. A reason such as paid means the workflow took that exit. Its reliability depends on the event and conditions you configured.
An explicit failed exit contributes to failed runs without requiring a platform error code. A handled step error remains visible in the individual run even when the overall run succeeds.
Compare versions and coverage
Review which published versions a view includes. A combined total can include older flows; a version comparison can reflect different traffic or periods as well as a workflow change.
Coverage indicators explain what the reporting period supports:
| Coverage | How to interpret it |
|---|---|
| Unavailable | The requested period has no covered reporting buckets. Missing data is not zero activity. |
| Partial | Part of the period is covered; comparisons need that limitation in view. |
| Provisional | The period is covered, but ongoing runs and reporting updates can still change values. |
| Complete | The period is covered and its run data is settled. This state is not yet used. |
Run detail and aggregate statistics have separate lifetimes. A retained total can remain after detailed run records expire or an automation is deleted.
Next steps
- Inspect individual runs.
- Troubleshoot an automation.
- Understand flows and connections.
- Browse the Automations guides.
相关资源
继续查阅此主题的文档、指南和示例。资源为英文。