I have received a reply from Quentin Armitage:
There is no configuration option that explicitly causes a delay in
VIPs being configured on a new master, but there are a couple of ways
I can think of that of that might achieve what you want (of course
having a delay is completely counter to the purpose of VRRP which is
about trying to minimise the downtime of a VIP being unavailable).
Option 1.
This will give longer downtime for an outage than for maintenance
(when I presume that keepalived is shutdown on the existing master).
Configure your VRRP instances to use VRRP version 3, an advert_int of
5 seconds, and your two VRRP instances to use priority 1 and priority
2 respectively.
In the event of keepalived being stopped on the original master (I
assume this is what is done for maintenance), it will send a priority
0 advert, and since the other instance has priority 1 it will wait
(256 - 1) / 256 * 5 seconds (i.e. 4.98 seconds) before taking over as
master (setting the advert_int to 5.02 will give you near enough an
exact 5 second delay). The disadvantage of this is that if there is an
outage, it will take between 15 and 19.98 seconds for the backup to
take over as master.
Option 2
Use a firewall to block access to the VIP until the new master is
ready.
You could use notify_backup and notify_master scripts to do this, but
the order of execution of notify scripts is not reliable, so you
should use a notify_fifo and a script to read the FIFO (see
vrrp_notify_fifo and vrrp_notify_fifo_script) in keepalived.conf(5)
man page. There is a sample_notify_fifo.sh script in the doc/samples
directory in the keepalived source tree, and it may be installed
somewhere like /usr/share/doc/keepalived by your distro.
When a backup message is received on the FIFO, add a firewall rule to
drop packets to the VIP. When a master message is received on the
FIFO, run a script asynchronously that sleeps 5 seconds and then
removes the firewall rule.
https://groups.io/g/keepalived-users/topic/is_it_possible_to_configure/81962597