Separate .log housekeeping from taking backups
If anything on the Windows side of the house prevents deletion of SQL Backup's own .log files, the Backup Service wastes time hunting repeatedly for said file(s) to delete, which can considerably (in my case from 2 seconds to 45 minutes per database) lengthen the execution duration, meaning that the potential data-loss window grows to the length of each run, which is unacceptable behavior.
Though rare, changing a service account can precipitate this run extension. Though rare, SQL Backup's response is to only warn of a deletion failure, and try again next time.
SEPARATION OF CONCERNS is a well-establish programming paradigm. Why doesn't SQL Backup adhere to it? What, in reality, does a housekeeping task that cleans up old .log files, have to do with the mission-critical job of taking data and transaction log backups?
May I politely request you split the functionality so nobody in future is subjected to delayed backups and the risks associated with backups not being taken at the appropriate interval.