The kind of details that @Stephen is pointing out are really important. Because we need to understand what zero downtime is, for example I could hack a Zero Downtime requirement by doing the following:
I define zero downtime as never responding to the user with a code other than HTTP 200 when the request is valid (keeping 300 and 400 open as needed). Then I deploy Discourse in a 10$ droplet in a one-container solution and add Adding an offline page when rebuilding to accomplish the no 500 errors. This way I don’t show a site that has been down.
Would I in a rational mindset think that this is zero downtime? Never. Does it works as proposed? Of course. And I could go ahead and add a standby server in another region to be even more zero downtime proof.
That is why qualification and semantics are important. Is not the same to always show something to always have functionality on the site.