The overall state of automation over a window: how many runs, how successful, how slow.
A skipped run is neither a success nor a failure
A run that never started because of rate control is counted separately and kept out of the success rate — out of the numerator and the denominator alike.
That is deliberate: counting skips as failures would make a deliberately throttled workflow look sick, and counting them as successes would inflate the rate.
So a high skip count is not a breakage — it is how the rate control is set.
Dead letters are the failures nobody caught
A failure that reaches an "on error" branch is a designed path and is not recorded here. What collects here are failures no one gave a path to, where the run genuinely stopped.
Each row keeps that step's input, so once the cause is fixed it is clear exactly what failed.
A row that has been dealt with can be closed so the counter reflects reality.
Average duration only sees finished runs
A run still going, or waiting, is not in the average. So a workflow that waits a week for an event does not drag the figure up.
Failure alerts are configured elsewhere
A workflow failure can raise an in-app notification or email a list of addresses. In-app is on by default and email is off — because there is no safe default address to mail.
That setting lives on the workflow itself, not here. This page shows the result.