We just updated our Jenkins to v2.207.1 and our build estimation times on pipeline jobs have stopped showing up. Rather than a blue bar that when hovered over shows an estimate, we are now seeing the blue-and-white striped barber pole and an estimation of N/A.

I believe this behavior might be only on pipeline jobs - we have so few freestyle jobs that I haven't seen them run yet.

What logic does Jenkins use to calculate those estimations? How many builds will we need before those times fill back in?

  • For freestyle or pipelines? Do you use bleuocean?
    – 030
    Mar 29, 2018 at 14:35
  • @030 Pipelines, as said. And yes we do use blueocean but this is not in the BO interface, but in regular jenkins.
    – Alex
    Mar 29, 2018 at 14:39

1 Answer 1


I checked out the Jenkins source code, and I believe Jenkins uses the last 3 successful or unstable builds for its estimation. If it out of the last 6 builds it can't find 3 successful or unstable builds, it uses 1 or more of the last completed (not aborted) builds. It then takes the total duration time of the "candidates" and simply divides it by the number of candidates (i.e. mean of the durations). Here is the code I based this off of that can be found in the Job.java file in the Jenkins repo:

     * Returns candidate build for calculating the estimated duration of the current run.
     * Returns the 3 last successful (stable or unstable) builds, if there are any.
     * Failing to find 3 of those, it will return up to 3 last unsuccessful builds.
     * In any case it will not go more than 6 builds into the past to avoid costly build loading.
    protected List<RunT> getEstimatedDurationCandidates() {
        List<RunT> candidates = new ArrayList<RunT>(3);
        RunT lastSuccessful = getLastSuccessfulBuild();
        int lastSuccessfulNumber = -1;
        if (lastSuccessful != null) {
            lastSuccessfulNumber = lastSuccessful.getNumber();

        int i = 0;
        RunT r = getLastBuild();
        List<RunT> fallbackCandidates = new ArrayList<RunT>(3);
        while (r != null && candidates.size() < 3 && i < 6) {
            if (!r.isBuilding() && r.getResult() != null && r.getNumber() != lastSuccessfulNumber) {
                Result result = r.getResult();
                if (result.isBetterOrEqualTo(Result.UNSTABLE)) {
                } else if (result.isCompleteBuild()) {
            r = r.getPreviousBuild();

        while (candidates.size() < 3) {
            if (fallbackCandidates.isEmpty())
            RunT run = fallbackCandidates.remove(0);

        return candidates;

    public long getEstimatedDuration() {
        List<RunT> builds = getEstimatedDurationCandidates();

        if(builds.isEmpty())     return -1;

        long totalDuration = 0;
        for (RunT b : builds) {
            totalDuration += b.getDuration();
        if(totalDuration==0) return -1;

        return Math.round((double)totalDuration / builds.size());
  • 1
    That clears things up nicely, thank you! Still odd that the bars aren't resolving when they've already run 2-3+ times on the new Jenkins, but at least I know how the behavior is expected to work. Something to keep an eye on I guess
    – Alex
    Mar 29, 2018 at 15:17
  • Glad I could help! I have always wondered how Jenkins derives these estimates. Your question gave me an excuse to look into it :) As for why you are seeing the wrong estimation, I always check plugin compatibility whenever I update Jenkins. Seemingly unrelated plugins can sometimes cause compatibility issues with other Jenkins components.
    – Preston Martin
    Mar 29, 2018 at 15:26
  • Very true. 030 had a good point about Blue Ocean, it seems like they're always to blame when we get weird gui errors. I'll have to do some testing and find out!
    – Alex
    Mar 29, 2018 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.