Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

If you see a little black clock icon in the build queue as shown below, it is an indication that your job is sitting in the queue unnecessarily.

The tool tip of the job name link next to the clock icon should tell you exactly why it is not building, but the common symptoms are as follows:

  1. Slaves are offline: your build needs to run on a particular slave, but the slave is offline. Go to http://server/hudson/computer/SLAVENAME to figure out why, and bring it back online. Or better yet, use labels and do not tie builds to specific slaves, so that a single offline slave will not prevent your builds from starving.
  2. Waiting for an available executor on a slave: your build needs to run on a particular slave, but the slave is already fully busy building other things, and your build is waiting for "too long" compared to the time it takes to execute it — in other words, it does not make sense to wait for 5 minutes when the build itself finishes in 2 minutes. Use labels so that builds can run on any machine that satisfies the system requirements, and in this way you can add more slaves to improve the turn-around time.
  3. Waiting for an available executor on a label: all the slaves that have the given label are fully busy doing other things. It is time to add more slaves.
  • No labels


  1. Unknown User (kishorerp)

    we use a multi config job to trigger jobs on multiple slaves

    when we trigger jobs on multiple slaves, during one of the subjob, if one of the slaves goes offline due to some system issue, the other slaves are starved and the other jobs do not progress at all, how do we auto abort above kind of build?

  2. Unknown User (keshlam)

    4. Someone has requested a Safe Reset on the server, and new jobs are being held off to let the server quiesce so it can be restarted. Assuming Safe Reset was implemented properly, this should be harmless and self-correcting, though there may be an extended delay while jobs already running are completed.