For deployments that include a database migration, both go offline to maintain data integrity, but one stays online until the actual deployment is ready to run, to reduce the window where both are offline.
Due to the majority of deployments being the former type (ie zero downtime), and those that have deployments being optimised to reduce the downtime, we don't bother with "scheduled" maintenance like you're talking about.
If it's something especially complex, `$CLIENT` has sometimes announced the outage to customers ahead of time on social media, but this isn't very common.
So if you want something super simple that will cause no downtime while switching over to a new version, just run two instances of your service, one on e.g port 9000 and the other on 9001.
At any time your proxy (nginx or traefik etc) will use only one of these.
Once you upgrade the version for the inactive one, you change the port used in nginx and reload it. Then the new version will be used.
idk what "deploying" means in your case.
but in general: try to keep the old deployment online as long as possible and switch to the new one after validating it ...
eg.
1. deploy to a new lets call it "location" - which could be a new directory, a new set of container-images, versioned packages for your linux distro (service managed by systemd) etc...
2. run & validate the newly deployed service-version
3. switch - by certain means, heavily depended on your setup
this should keep the downtime within fractions of a second - if this is feasible for your application.
but in the end a viable solution depends on your actual deployment-process :)
just my 0.02€