Los tipos de detalles que @Stephen está señalando son realmente importantes. Porque necesitamos entender qué es cero tiempo de inactividad, por ejemplo, podría eludir un requisito de Cero Tiempo de Inactividad haciendo lo siguiente:
Defino cero tiempo de inactividad como nunca responder al usuario con un código distinto a HTTP 200 cuando la solicitud es válida (manteniendo los códigos 300 y 400 abiertos según sea necesario). Luego, implemento Discourse en un droplet de 10 $ con una solución de un solo contenedor y agrego Add an offline page to display when Discourse is rebuilding or starting up para evitar errores 500. De esta manera, no muestro un sitio que ha estado caído.
¿Pensaría con una mente racional que esto es cero tiempo de inactividad? Nunca. ¿Funciona como se propone? Por supuesto. Y podría incluso agregar un servidor de respaldo en otra región para ser aún más a prueba de cero tiempo de inactividad.
Por eso son importantes las calificaciones y la semántica. No es lo mismo mostrar siempre algo que tener siempre funcionalidad en el sitio.