Learn · Diagnosing the platform

Where the time actually goes

A build’s wall-clock time is not one number. It is at least four, and they have different owners.

Queue wait — the job is created and waiting for an agent. Owned by the platform, if it is genuinely waiting for capacity.

Runtime — the job is executing. Owned by whoever writes the tests.

Gate wait — the job could run, an agent is free, but a concurrency group is full. Owned by whoever set the gate, and it is usually working as intended.

Approval latency — a block step is waiting for a person. Owned by nobody’s infrastructure. It is someone at lunch.

Why this ordering matters

The first three are visible in a build’s anatomy. The fourth frequently is not, because many measurements roll block-step waiting into “wait time” without distinguishing it.

That produces a specific and expensive failure: a chart showing wait time climbing, a reasonable conclusion that the platform is under-provisioned, and a capacity recommendation that cannot possibly help — because the time being measured is a human’s, not the platform’s.

Before you recommend capacity, ask of the waiting jobs:

1. Is there an idle agent in the queue they target? If yes, it is not capacity.
2. Do they share a concurrency_group? If yes, they are queued by design.
3. Is there a block step upstream? If yes, you are measuring a person.
4. Does the queue they target have any agents? A typo produces infinite wait.

Only when all four are ruled out is “add agents” the answer.

The distribution matters too

An average hides a bimodal build. If most builds take four minutes and a nightly job takes ninety, the mean describes neither, and optimising toward it optimises toward a build that does not exist.

Look at p50 and p90 separately, and look at what is actually in the p90 bucket before concluding anything about it.