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

Plugin Information

View Naginator on the plugin site for more information.


This plugin allows you to automatically reschedule a build after a build failure.

This can be useful in several cases, including:

  • The build is dependent upon external resources, that were temporarily unavailable (DB down, network down, website down, etc).
  • Users want continuous emails sent out until the build is fixed, in order to prompt people into action.


Simply install the plugin, and then check the Post-Build action "Retry build after failure" on your project's configuration page.

If the build fails, it will be rescheduled to run again after the time you specified. You can choose how many times to retry running the job. For each consecutive unsuccessful build, you can choose to extend the waiting period.

The following options are also available:

  • Rerun build for unstable builds as well as failures
  • Only rebuild the job if the build's log output contains a given regular expression
  • Rerun build only for the failed parts of a matrix job

The plugin also adds a rerun button for in the build section.


To report a bug or request an enhancement to this plugin please create a ticket in JIRA (you need to login or to sign up for an account). Also have a look on How to report an issue

Key T P Summary

Version History

Version 1.18 - Feb 23, 2019

  • Now targets Jenkins 1.565+ (was 1.554+)
  • FIXED: wrong delay time calcuration in "Progressive" strategy when there're multiple series of retries in parallel: JENKINS-43803 - Getting issue details... STATUS
  • FIXED: links to the source builds in cause texts are broken when the build number gets 1000+: JENKINS-50751 - Getting issue details... STATUS

Version 1.17.2 - Aug 14, 2016

  • Don't display "Retry" link for pipeline builds (JENKINS-36438)
    • It caused NPE. Naginator doesn't works for pipeline builds for now.

Version 1.17.1 - Jun 05, 2016

Version 1.17 - Mar 12, 2016

  • Makes the build number of the naginator cause a clickable link (#25)
  • Displays the checkbox for matrix projects even when the publisher is newly added (JENKINS-32822).
  • Added "When no combinations to rerun" (JENKINS-32823).
  • Introduced a new option "How to apply the regular expression to matrix" which replaces "Test regular expression for the matrix parent" (JENKINS-32821)

Version 1.16.1 - Dec 06, 2015

  • Fixed: Retry button invisible even with "Build" permission for a project (JENKINS-31318)
  • Fixed: Bad regular expressions cause unabortable builds (JENKINS-24903)
    • Too long running regular expressions will be aborted. You can change the timeout for regular expressions in Configure System page.

Version 1.16 - Oct 31, 2015

Version 1.15 - Apr 9, 2014

  • (info) Make JobProperty optional for jobs
  • (info) Decrease require core for ancient jenkins users

Version 1.14 - Dec 19, 2014

Version 1.13 - Nov 12, 2014

  • Fix progressive delay time calculation (behavior slightly changed)
  • Fix rerun behavior for unstable builds in matrix
  • Better log the trigger cause
  • Fix badge icon for the case in which Jenkins is not in the root folder
  • Don't show rerun link if user doesn't have permissions

Version 1.12 - Aug 25, 2014

  • Added the option to rerun only the failed parts of a matrix
  • Retry will occur only when all parts of a matrix finish
  • Rebuild link verify authentication
  • Don't rerun job on manual cancel
  • Fix NPE when running Maven build

Version 1.11 - April 8, 2014

  • Naginator now retain original build causes on retry

Version 1.9 - Nov 8, 2013

  • Re-schedule limit doesn't consider previous builds that aren't related to Naginator
  • Added a badge icon to re-scheduled builds
  • Bug fixes

Version 1.8 - June 12, 2012

  • New extension point to configure schedule delay
  • Fixed delay implementation
  • Parameters for build are reused on schedule
  • Limit for number of build attempts after failure

Version 1.7 - May 31, 2012

Version 1.6.1 - May 3, 2012

  • Fix compatibility with build-timeout plugin (JENKINS-11594)
  • Use a RunListener

Version 1.6

  • Not released (release:prepare failed on ndeloof computer :-/)

Version 1.5 - Dec 7, 2009

  • Added support for not rebuilding if the build is unstable.
  • Added support for only rebuilding if a regular expression is found in the build log.

Version 1.4 - Jan 26, 2009

  • The plugin progressively introduces a delay until the next build. It starts with 5 minutes and goes up to one hour.

Version 1.3 - April 9, 2008

  • After way too long, the release is actually out there. 1.1 and 1.2 are missing due to my inability to use the maven release process correctly (big grin) .

Version 1.0 - Sept 17, 2007

  • Initial Release - release didn't actually make it to the repository...


  1. Unknown User (ckutz)

    I'm not quite sure what reschedule means in this case? Is the next build started immediately after the failed build (possibly delyed by the quiet period?)?

    It would be very helpful to have a cooldown period before rescheduling the build. IMO it is very probable that an external resource is still unavailable when you restart the build immediately. But if you wait for some time chances are higher that it is available again.

    Edit: I just found out that the schedule-failed-builds plugin does something like that.

  2. Unknown User (dtka)

    Would be cool to have an option to rebuild a failed/unstable parametrized build with the same parameters. This are getting lost at the moment. A bit like Rebuild Plugin, but automatically.

  3. Unknown User (mingzhu)

    Excellent plugin in. Thank you!

  4. Unknown User (dabrahams)

    Strange, I don't see the "Reschedule build after failure" checkbox anywhere on my project's configuration page.  What am I missing?

    (yes, the plugin is installed).

    1. Unknown User (robertbw)

      I have the same issue. It doesn't re-run my build so I'm trying to find out why and I don't see that checkbox either. Is the description up to date?

      1. Unknown User (dilipm79)

        It seems to be under Post Build section as
        "Retry build after failure"

  5. Unknown User (zioschild)

    We're using the plugin since a long time and especially for network-jobs with unstable connections this plugin works great. Thx.
    Am I right: aborting a build manually will cause a rebuild as well? Is it possible to suppress (manually) aborted jobs from rebuild?

    1. Unknown User (galunto)

      Solved now

  6. Unknown User (tmcmurra)

    Can anyone point me to info on configuring this plugin. I installed it but my job doesn't auto restart.

    I've checked "Rerun Build" , Fixed Delay of 60, "Max number of successive failed build" = 3. I'm running Jenkins in RedHat as a daemon and there is nothing in the log file. Are the parms documented anywhere. This plugin has potential but the abysmal lack of documentation makes it very frustrating. Thanks for any help.

  7. Unknown User (ankurbadola)

    Anyone can point to how to release newer version? There is no release after 1.8. I am interested in this fix:

    • re-schedule limit doesn't consider previous builds that aren't related to naginator
    1. Unknown User (oleg_nenashev)

      1. Go to the jenkins-dev Google group
      2. Ask about the new release
      3. If there's no answer, feel free to request committer rights and to release plugin on your own

      Unfortunately, many plugin have not active maintainers... 

  8. Unknown User (schleprock)

    as others have noted, this could be a great plugin but the documentation is aweful. i'm trying to use the fixed -> delay before retrying parameter and have no idea what the units are for this value. at a minimum it would be nice to add a pop-up to this parameter indicating the units. if anyone knows what the units are, please post!


  9. Unknown User (davida2009)

    Please update 'Version History' on this page with the changes for versions 1.10 and 1.11.

    1. Unknown User (galunto)

  10. Unknown User (sion_oc)


    The retry works well but if the job is a triggered with parameters job the Parent caller job will fail (doesnt see its being retried).

    To me this is just a respawn with same parameters functionality. A retry should not have a build result until all the retries are finished. this means that if you set an email on failure wouldnt be triggered until all retries have failed.

    Many Thanks


  11. Unknown User (jamil_nyc)

    What are the units of the fixed delay, seconds or minutes?

    1. Unknown User (jamil_nyc)

      It is in seconds if anyone is wondering.

  12. Unknown User (jamil_nyc)

    It would be great if this plugin worked with the email-ext plugin. Right now, any try that fails sends out a failure email and there isn't a clear way to distinguish an automatic retry in the email.

  13. Unknown User (rnester)

    This plugin seems to "forget" that it's supposed to be retrying builds. By which I mean the following:

    • I have a job which executes some basic python scripting. 
    • This job is configured to retry the build up to 7 times.
    • This job is configured with a delay of an hour between each retry attempt 

    What I see is that Naginator often seems to "forgets" that it is supposed to be retrying.
    It might rebuild 3, 4, 5 or 6 times, and then no longer reschedule the build in question.

    This seems to be most prevalent when there are multiple builds of the same job occurring simultaneously, although that is very anecdotal.

  14. Unknown User (z221700)

    I have a question about rerun failure build.

    I run a project which contain two class A and class B.

    First Build: Class A is pass and Class B is error. then rerun the second build and both of them run in the second time.

    But I only want to run the Class B. Because Class A is OK, I just need to check Class B.

    Some project I need to check a lot of case and if it run at the beginning, it will cost a large time and I do not want to do this.

    Is it possible that Naginator just rerun the failure in next build?

  15. Unknown User (thecrumb)

    "Rerun build for unstable builds as well as failures"

    Would be more flexible if I could rerun on unstable / aborted OR failure.  Maybe series of checkboxes for each?

    Currently I'd like to rerun on aborted job but not failures.

  16. Unknown User (pakapi)

    I think Naginator rerun should depend on Build triggers. For example:

    |'ve got job, which builds periodically since 8 a.m. to 9 p.m, but if job  fails at 8:59 p.m, naginator reruns this job. Let's assume that at 09:05 p.m this job failed. Naginator will rerun job without checking time boundaries.Should I report it on JIRA?

  17. Unknown User (sbonami)

    Hi, is there a way to add a parameter when a user clicks on the "Retry" button. For example, I want the user to write the reason when he clicks on "Retry". Thanks.