You wait at most 60 seconds, not at least.
this would require accepting runtime control requests on the TCP port, and deciding on authorisation - the simplest being "superadmins only"
@volter I wrote at least, since the deployment software needs to wait 60, becaue if you wait less then 60 seconds, the maintenance might not be enabled.
@richlv This problem could be solved in other ways, e.g. server could listen if a file was changed (which can be configurable in the configuration file), and the web server could touch that file or something similar.
Of course if the API is moved to the server, then this should be relatively easy to implement and probably won't be even needed, since the configuration changes could be instant. So that is one more reason to move API to server.
frontend already needs tcp port access to the server for a bunch of features, but it doesn't need a common fs with the server - introducing such a dependency might not be a good approach
If it needs a TCP connection to the server for other things, then that is fine 
I would totally be ok if maintenance.create/update would send a trigger to the server over TCP to read maintenance again (e.g. trigger configuration reload), since you shouldn't need to be a super admin to set maintenance. I don't remember ever needing the reload a configuration for anything, but maintenance.
In addition to configuration.reload we also need a way to check the last sync completion time. On loaded systems sync is not instantaneous.
Indeed, in enterprise environments one often doesn't have Unix access to the servers so -R is absolutely not an option.
Related (frontend): ZBXNEXT-3448.
I think that with the introduction of real-time configuration sync in Zabbix 6.x this functionality is no longer make sense. I am closing it.