Learn · Diagnosing the platform

Hands-on: prove where a job ran

Reading about targeting is not the same as watching a job land where you intended. This unit is done in your own organisation.

Your task

Create a pipeline with a root-level agents default and one step that overrides it, so that two steps run on two different queues:

agents:
  queue: "default"

steps:
  - key: here
    command: |
      buildkite-agent meta-data set "cert-practice" "<your nonce>"
      echo "ran on $BUILDKITE_AGENT_META_DATA_QUEUE"

  - key: elsewhere
    command: echo "ran on $BUILDKITE_AGENT_META_DATA_QUEUE"
    agents:
      queue: "other"

You will need agents in both queues. Starting a second agent locally with a different queue tag is enough:

buildkite-agent start --token "$AGENT_TOKEN" --tags "queue=other"

Run the build, confirm the two steps report different queues, then paste the build URL below.

What you should notice

If you start only one agent, the second step does not fail. It waits, quietly, with no error and nothing in the logs — because from Buildkite’s perspective nothing is wrong. A job is queued and no agent has claimed it.

That is the failure mode from the previous unit, reproduced deliberately. It is worth seeing once in a system you control, because the next time you meet it will be in a customer’s organisation at an unhelpful hour.

The nonce ties this build to you. A URL copied from someone else will not verify.

How this is checked

Not by reading your pipeline file. Verification reads which agent claimed each job and reports the queue that agent belongs to — so it establishes where the work actually ran, which is a different claim from where the YAML asked it to run. Writing the targeting correctly and having no agent in the second queue does not pass.