When using Jenkins to trigger some process (eg a remote build) at a remote location, why would you ever want to "fire" something, and then just "forget" about the outcome of what got triggered remotely? At least that is what "fire and forget" seems to be about.

Such "fire and forget" sounds like not respecting some of the basic rules in IT: in whatever process (or program, etc) you write, try to always be prepared for unexpected conditions (return codes, etc) that may arise. So that you'll also have appropriate error handling in place.

To the extend it does make sense, in the (mainframe) SCM tool that I'm most familiar with, you'd start some FTP process from a dev environment to a remote target (eg to distribute and activate executables). And sooner or later (asynchronously) somebody gets some kind of acknowledgement back (from the remote target to the dev site) that indicates "success or failure". And if within a reasonable amount of time no feedback at all is returned, you know that something is not working as it should. Using such scenarios, you'll never forget what got fired.

Any examples for which using "fire and forget" in Jenkins does make sense?

  • Because the task is responsible of alerting if something goes wrong, that's not the scheduler job to supervise it at all if nothing depends on it. E.g: a daily backup, the scheduler just have to fire it up at the right time once batches have ended, it's the backup task duty to catch errors and warn about them. The scheduler state of failed would not bring any information to act on. Separation of duties at code level :)
    – Tensibai
    Commented Mar 29, 2017 at 20:20

3 Answers 3


I wouldn't describe Jenkins jobs as "fire and forget." They are designed to run automatically without the need for human interaction, however, that doesn't mean the result of a job is not visible. Quite the opposite- detailed logs of all activity are available for jobs ranging from command-line tools to custom deployment jobs.

The testing results from Jenkins jobs are routinely displayed on large-screen TVs all over the Development floor of many companies I've seen. There are whole plugins devoted to making this type of information available to developers, Ops, and management in a dashboard format.


In this case, "Fire and Forget" doesn't mean what you think it means.

It isn't the case that you fire the build and then forget about the outcome. What actually happens is that you fire the event, and then forget about what the process is doing up until the point where the process returns feedback to you and reminds you about what was fired.

As an example, the old way of doing things might be to trigger a build and then let it run while you watch the output. You sit there watching the results of the build as they occur and don't work on anything else productive during that time. Or you do work on something productive, but you have one eye on the build process. When it is done, you need to either be paying attention, or remember to check on it to see the results and then continue based on that.

In Jenkins model of "Fire and Forget", you have some automated process do the build for you, and your mind is not focused on the build process until something goes wrong, or the build completes. At that point, you get a message from Jenkins, either as an email or in a program like slack, which now reminds you of the build process and tells you all the information you need to know to move on. In the meantime, you were working on some other task with your full focus, because you knew that you didn't have to keep an eye on it. The automated system would alert you to anything you needed to know.


It seems like forget in this context is not really what it sounds like. Instead it is rather something like "Don't keep me waiting for the process to complete, so that I can do something else while the process is running. And when the process is done (succeeded or failed), we'll continue processing with whatever is next".

An example 'for which using "fire and forget" in Jenkins does make sense' (as in my question) is creating parallel chains to reduce the duration of pipelines, and combine it with using the Join plugin. Some more details about this plugin (from the linked page):

This plugin allows a job to be run after all the immediate downstream jobs have completed. In this way, the execution can branch out and perform many steps in parallel, and then run a final aggregation step just once after all the parallel work is finished.

The plugin is useful for creating a 'diamond' shape project dependency. This means there is a single parent job that starts several downstream jobs. Once those jobs are finished, a single aggregation job runs.

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.