First thing I'd check is "what changed?". If it worked prior to a certain date and suddenly stopped working, something changed. Step 1 is to figure out what changed and once you figure that out, you can debug the problem.
A script won't just "stop working" unless something changed.
Also, it is due to problems like that, that I prefer to write my own scripts. I can target the scripts to my specific environment and setup and don't need the extra "fluff" that is in Ola's script. For example, I run SQL Backup (RedGate tool) for my backups. So my scripts target SQL Backup explicitly rather than Ola's that SUPPORT SQL Backup, but also support native backup and other 3rd party backup solutions. I like short and specific stored procedures as they are easy to test and it is easier to debug than a huge script. Plus if you need to add features, it is much easier to do it if the scripts are short and specific. Like if you don't do differential backups at the moment, then you may exclude those from your backup script. BUT if you need differential backups in the future, you only have 1 short script to add that into. I currently have a stored procedure for index maintenance, one for backups (log, full, and differential), one for statistics updates, and one for backup cleanup. 4 stored procedures that are easy to test and debug and if they get too long, complex, or too hard to debug, I can break things out like having 3 for backups depending on the backup type.
Also, you posted this under SQL2019 admin and are asking about SQL 2016. You may get better answers in the 2016 section of the forum.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.