Q:

Is it bad practice to use a CI server for cron/scheduled tasks

Is it considered bad practice to use something like Jenkins or Gitlab CI Pipelines to replace cron jobs?
There are two downsides I can think of, giving the CI server access to all servers and having a single point of failure (if the CI server is down no scheduled tasks can run).
Typically the cron jobs running on our example servers are associated to a git repository.
This is in an effort to remove the need for developers to connect into servers to check and/or manage crons and cron failures, as well as being able to manage these in one central place.
Would this be better placed in a configuration management tool (Puppet/Salt/Chef/ansible)?

A:

Make your own design decisions about which tools to solve the problems. There is no one answer, only a choice between various trade-offs.
No one should be getting a shell, but some cron jobs need to be managed. So, write automation to install and verify cron jobs on each host. Maintain the automation in version control, and trigger it via CI.
Availability and performance of the CI server may be a concern. Address this by implementing high availability and scaling larger.
cron is a basic scheduler, and while it reliably runs jobs on the minute, it is limited. Consider implementing a system with more features, including logging and diagnostics.

