Os tipos de detalhes que @Stephen está destacando são realmente importantes. Porque precisamos entender o que é tempo de inatividade zero; por exemplo, eu poderia burlar um requisito de Tempo de Inatividade Zero fazendo o seguinte:
Eu defino tempo de inatividade zero como nunca responder ao usuário com um código diferente de HTTP 200 quando a solicitação é válida (mantendo os códigos 300 e 400 abertos conforme necessário). Então, eu implanto o Discourse em um droplet de 10$ em uma solução de um único container e adiciono Add an offline page to display when Discourse is rebuilding or starting up para evitar erros 500. Dessa forma, não mostro um site que esteve fora do ar.
Eu, em uma mente racional, acharia que isso é tempo de inatividade zero? Nunca. Funciona conforme proposto? Claro. E eu poderia até adicionar um servidor de reserva em outra região para ficar ainda mais à prova de tempo de inatividade zero.
É por isso que qualificação e semântica são importantes. Não é a mesma coisa mostrar sempre algo do que sempre ter funcionalidade no site.