So it looks like setting --no-autorenew stops even our own scripts from renewing. A cert had expired today and when my script is run (which uses sudo /usr/bin/certbot renew) it says skipped for that domain:
/etc/letsencrypt/live/domain.com/fullchain.pem expires on 2024-10-02 (skipped)
Is that the expected behaviour? If so perhaps as Rudy originally said it may just be better to stop the scheduled tasks from running - however I can't find them 
On this page: Certbot Instructions | Certbot it says:
The command to renew certbot is installed in one of the following locations:
/etc/crontab//etc/cron.*/*systemctl list-timers
There's nothing in the crontab file:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
And also relating nothing to letsencrypt in the cron. files (other than my own script):
cron.d/ cron.daily/ cron.deny cron.hourly/ cron.monthly/ crontab cron.weekly/
Nor is there anything listed with systemctl list-timers.
I suspect then that when my script runs certbot renew Certbot goes ahead and renews whichever domains it sees fit (ignoring our 30 day window) so perhaps all I need to do is just ensure my script does all the additional bits it needs to do for every domain every day just in case certbot has renewed that domain.
Does that seem like a good way forward?
Or should I check in a specific location for the scheduled task?