Why did this run happen?

Why did nothing run?

The most common question in CI has the least satisfying answer anywhere: an empty run list. A push that matched no workflow, a path filter that said no, a branch filter that excluded it — they all look identical from the outside, and working out which one it was means opening the file and reading the filters back to yourself.

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 job on Apex records the exact invocation it ran. apex reproduce prints it for your machine, with every secret named and never carried — you supply the values, the command supplies everything else.

apex reproduce 8123 --job test

apex reproduce is not yet available to customer accounts.