I would have to agree with this. I don't know what state of the art Jenkins is in now, but our company does infrastructure as code. I don't think Jenkin's would

I would have to agree with this. I don't know what state of the art Jenkins is in now, but our company does infrastructure as code. I don't think Jenkin's would pass muster. I think we would see the UI as a major liability as time goes on. If we ever needed to migrate off the instance of Jenkins or a plugin is no longer supported, or a million other things, Jenkins is a rather large deployment for running scheduled tasks. There would be too many specialized things installed or hand manipulated for us. We already had major issues with another company basically hiding a lot of packed crap all over the place, so infrastructure as code has helped a lot. We ended up writing 114 line typescript job scheduler that uses Mongodb as a store. Mongodb provides the atomicity of scheduling (find and modify). Beyond that our UI is Robo 3T. The job collection has 4 simple states. Any process can write a job document with the earliest time the document can run. It is also scaled with the rest of our application: more instances, more jobs that can run simultaneously. But... I can see in shops that don't have this complexity yet, Jenkins might be just fine. Edit to add: We decided against using another data source like a Queue which is something we would have used a long time ago, but we're already at an infrastructure complexity point where it would not be worth it - we already have Elasticsearch, MongoDB and Mysql so adding a AWS queue or rabbit would be out of the question at this point unless it provided a massive functionality we would need for something else.