The lack of a hook for restarting Apache is probably also somehow justified.

I changed the settings. Made updates weekly and added an action for Apache.

Therefore all such renewal processes have "busy wait" design that begins with the test if it's yet time for a renewal and return as failure if not. If it is time for renewal, an actual renewal attempt is made, and that may succeed or fail for external reasons. If it fails, then the next run will again discover that it (still) is time for renewal and make another attempt. Etc. When the renewal succeeds,  the local state changes so the next run will again opt out early because renewal is not (yet) needed.

Now, both that check for systemd and that randomized delay are unnecessary components. Your system does not need to check and re-check for the presence of systemd, since that is a constant.  And you can choose a random but fixed start time  for your certbot runs, which will be an equivalent collegial measure for avoiding clogging the remote end when actual renewal requests are made (there is no statistically motivated reason to pick a new random start time every time).

It's kind of sick, that cron looks (or has to look) for systemd.timers, but anyway.

test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))'

This code raises questions for me.

Accordingly, it seems to me that the standard cron task is either not quite suitable for devuan or in principle needs to be improved by the administrator.

Does this mean that the apache2 service will reload (not restart) twice a day (*/12)? It's not scary, but it's not necessary. IMHO.

If you tell the job to do it that is what it will do. I for one fail to see why you would be trying to renew a certification twice a day as it is. I would think a monthly job at the most would be the idea or depending on the length of the certificate a yearly job would most likely be the best. This twice a day foolishness in the comments make very little sense if their process is that useless it is needed I would not be trusting them for anything as critical as security of my website. You could do a separate script for the apache2 reload that wold test something like the date on certificate then it will only reload if it has changed.

Should i add --post-hook "service apache2 reload" to

I would give.

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew && service apache2 reload

A try using the same idea it does after the certbot renews the certificate perhaps even /etc/init.d/ apache2 reload as the command to ensure no stupid path problems as happens with cron as it does not have the same path as the user does when it tries to execute commands. I always do this with my entries to ensure it has no choice but to do what I tell it to do. For example my root crontab.

root@9600k:~# crontab -l
# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
snip....
# m h  dom mon dow   command

## Run my rsync snapshot script at fifteen minutes after it every four hours.
15 */4 * * * /root/bin/snapshot_root.sh  > /dev/null 2>&1
## Run trim on my SSD drives every Saturday at 5am borrowed idea from MX Linux.
0 05 * * sat /root/bin/fstrim-MX.sh > /dev/null 2>&1

should certbot deb package from Debian be patched for Devuan?

No it tells you that changes are needed if running systemd which Devuan does not do so it is proper as it is. The line in the package is correct, the line you suggest to use is the one that is wrongly formatted with the 0,12 shown by you.

this cron task is from original package:

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

Your cron entry misses the user field.

Also has error with the 0,12 instead of the properly shown 0/12 for every twelve hours in the example above it for the hour to run field.

May be you'd need the full path of certbot, you just check it out, because I'm not sure.

Is it good for devuan?

cat /etc/cron.d/certbot
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
#
# Important Note!  This cronjob will NOT be executed if you are
# running systemd as your init system.  If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob.  For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

I think about something loke this:

0 */12 * * * root certbot renew --post-hook "service apache2 reload"

0  0,12 *  *  * certbot renew --post-hook "service apache2 reload"