mailerpress/get-workflow-stats returns aggregate execution stats for one workflow: total runs, active jobs, completed jobs, failed jobs, exit jobs, and per-step throughput.
The per-step throughput is what diagnoses a workflow.
At a glance
| Ability | mailerpress/get-workflow-stats |
| Toolset | MailerPress — toolset/mailerpress |
| Group | MailerPress › Workflows |
| Requires | AcrossAI Pro, plus MailerPress active on the site |
| Capability | manage_options |
| Safety | Read-only — changes nothing |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Pro 0.9.16 and later |
How it works
A workflow with a hundred entries and two completions has ninety-eight people stuck somewhere, and the throughput per step says where. A step with entries and no exits is the blockage.
Exit jobs are distinct from failed ones. An exit is a contact leaving the workflow because a condition sent them out — which is by design — while a failure is something going wrong.
Conflating the two makes a working workflow look broken, which is why they are counted separately.
Active jobs are contacts currently in flight. That number is why disabling a workflow does not stop it immediately: those people are already inside it.
Zero total runs on an enabled workflow means the trigger never fires — a wrong trigger key, or a hook that does not happen on this site.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
id | integer | Yes | The workflow. |
What comes back
| Name | Type | What it is |
|---|---|---|
stats | object | Total runs, active, completed, failed and exit jobs, with per-step throughput. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Is that automation working?
It resolves to one call:
{
"ability": "mailerpress/get-workflow-stats",
"parameters": {
"id": 21
}
}Worth knowing
- A step with entries and no exits is the blockage.
- Exits are by design; failures are not. They are counted separately.
- Active jobs are why disabling does not stop a workflow immediately.
- Zero runs on an enabled workflow means the trigger never fires.
Related abilities
- MailerPress Get Workflow Logs — the per-job detail
- MailerPress List Failed Workflow Jobs — failures across every workflow
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category