An executor is a slot on a node that runs one piece of work, usually one per spare CPU core. Every build first passes through the build queue: waiting (quiet period), blocked, buildable (no suitable executor free), then pending.
To watch it, the listing sets the built-in node to zero executors (Controller-Agent Trust explains why), then triggers the Pipeline job queue-demo, whose whole script is node('linux') { sh 'sleep 20' }, three times in a row and once more twelve seconds later:
J=http://localhost:32080; AUTH="admin:$JENKINS_TOKEN"
curl -s -u "$AUTH" --data-urlencode 'script=Jenkins.get().setNumExecutors(0)' $J/scriptText
for i in 1 2 3; do curl -s -u "$AUTH" -X POST $J/job/queue-demo/build; done
curl -s -u "$AUTH" $J/queue/api/json | jq -r '.items[].why'
sleep 12
curl -s -u "$AUTH" -X POST "$J/job/queue-demo/build?delay=0sec"
sleep 4
curl -s -u "$AUTH" $J/queue/api/json | jq -r '.items[].why'In the quiet period. Expires in 4.9 sec Waiting for next available executor on ‘agent-1’
Four triggers made two builds. The quiet period (5 seconds by default) exists to fold duplicates: the second and third requests were merged into the waiting item, so build 1's log begins with "Started by user BookNest Admin" three times and its build.xml counts the cause as <int>3</int>. The fourth trigger skipped the quiet period, started build 2, and its node block waited until build 1 released agent-1's only executor.
What did not wait was the Pipeline itself. Its Groovy program runs on a flyweight executor, a temporary slot on the controller that needs no free executor; only node blocks take the regular, heavyweight executors. A queue full of "Waiting for next available executor" means you are short of agents, not of controller capacity.