Why did this run happen?

Why did nothing run?

The most common CI question has the least helpful answer on GitHub: silence. A push that matched no workflow, a path filter that said no, a branch filter that excluded it — the run list is just empty.

On Apex, every push leaves a verdict for every workflow file in the repository, including the ones that ran nothing. The verdict names the filter that said no, as the workflow wrote it. You never wonder whether the workflow is broken or the filter is working.

Which test is flaky?

A flaky test is a disagreement at one commit: the code did not change, and the result did. That is the only definition that cannot be argued with in a review — a failure rate would confound a test that is nondeterministic with one that was broken and later fixed.

Apex reads the test reports your job already produces — JUnit, TAP and CTRF, discovered in the workspace with no change to the workflow — and names the tests that disagreed with themselves. A flaky test reaches the pull request as one warning, never a second failure. The matrix leg is part of the identity, so a test that flakes only on one platform is reported as exactly that.

Why was this run slow?

Every step carries an interval, and every run is compared against its own history for that workflow and that matrix leg. The steps that ran slower than they usually do are called out on the run, with the numbers. The log is still there; you just do not have to read it to find the gap.

Reproduce a failed job locally

A failed job on Apex records the exact invocation it ran. One command prints it for your machine, with every secret named and never carried — you supply the values, the command supplies everything else.