O que é uptime e como ele é calculado em cloud?

Uptime é o percentual de tempo em que um sistema, serviço ou infraestrutura permanece disponível e operacional em um dado período. O inverso — o tempo em que o sistema esteve indisponível — é o downtime. Em cloud computing, uptime é a métrica que fundamenta SLAs contratuais e define o limite máximo de interrupção tolerada.

Definição e fórmula de cálculo

O cálculo é direto:

Uptime (%) = (Tempo total - Tempo de downtime) / Tempo total × 100

Pense assim: em um mês de 30 dias (43.200 minutos), se o serviço ficou fora por 20 minutos:

Uptime = (43.200 - 20) / 43.200 × 100 = 99,953%

Downtime é qualquer período em que o serviço não responde dentro dos parâmetros contratados — seja por falha de hardware, atualização não planejada, falha de rede ou indisponibilidade de aplicação.

A tabela dos “nines” — o que cada nível significa na prática

A indústria usa o número de “noves” (nines) como forma abreviada de expressar uptime. A diferença entre 99% e 99,99% parece pequena nos decimais, mas é enorme em minutos de downtime por ano.

Referência de cálculo: ano comercial = 365 dias = 525.600 minutos; mês = 30 dias = 43.200 minutos.

Imagine que você tem um e-commerce e o SLA do provedor é 99,9%. Isso significa que, contratualmente, o serviço pode ficar fora quase 44 minutos por mês — e se esses 44 minutos caírem numa sexta-feira à tarde, o impacto no caixa é real. O salto de 99,9% para 99,99% reduz o downtime anual de ~8,7 horas para ~52 minutos, uma diferença decisiva em qualquer cenário com impacto financeiro direto. Para a maioria dos sistemas de negócio — ERPs, portais e-commerce, plataformas SaaS — o patamar mínimo aceitável é 99,9%. Aplicações críticas (financeiro, saúde, infraestrutura) precisam de 99,99% ou superior.

Uptime de hardware vs. uptime de serviço

Na prática, essas duas métricas são frequentemente confundidas — e a confusão tem consequências.

Uptime de hardware mede a disponibilidade física do equipamento: servidor, switch, storage. Um servidor pode estar ligado e respondendo ao ping, mas com uma aplicação travada ou um banco de dados inacessível.

Uptime de serviço (ou uptime de aplicação) mede se o serviço entrega respostas válidas dentro do tempo esperado. É o que realmente importa para o usuário final e para o SLA contratual.

Em cloud pública e privada, o SLA do provedor cobre tipicamente a camada de infraestrutura — hypervisor, rede, storage. A disponibilidade da aplicação que roda sobre essa infraestrutura é responsabilidade de quem opera a aplicação. Contratos bem escritos distinguem os dois escopos claramente.

O que causa downtime em ambientes cloud

O problema real aqui é que a maioria dos incidentes de alta disponibilidade não vem de falha catastrófica de datacenter — vem da ausência de redundância na arquitetura da própria aplicação. As causas mais comuns de downtime não planejado são: falha de hardware (disco, placa de rede, fonte sem redundância ativa), falha de rede (perda de uplink, roteamento incorreto, saturação de banda), erro humano (configuração errada, deleção acidental de VM ou regra de firewall), falha de software (bug em atualização de hypervisor, kernel panic, deadlock em banco de dados) e capacidade esgotada (CPU, memória ou IOPS acima do limite provisionado).

Uma instância única em qualquer nível — aplicação, banco, load balancer — é um ponto único de falha independente do SLA do provedor. O SLA protege a infraestrutura; a arquitetura protege o serviço.

Como monitorar uptime em cloud

Monitoramento efetivo exige verificação ativa (synthetic monitoring), não apenas observação passiva de métricas de infraestrutura. Você precisa monitorar em várias camadas: a disponibilidade da instância (o hypervisor reporta a VM como ativa?), a conectividade de rede (respostas a pings ICMP e verificações TCP na porta do serviço), o health check da aplicação (endpoint /health retorna HTTP 200?), a latência de resposta (o serviço responde dentro do tempo máximo aceitável?) e a integridade dos dados (queries de teste no banco retornam resultados corretos?).

Ferramentas comuns: Zabbix, Prometheus + Grafana, Datadog, UptimeRobot, New Relic. Para ambientes críticos, faz sentido monitorar de pelo menos dois pontos externos independentes — assim você distingue falha real de falha no próprio monitor. Configure alertas com janelas de tolerância (por exemplo, alerta após 2 minutos de indisponibilidade) para evitar falsos positivos por picos transitórios.

Para conhecer o SLA contratual da infraestrutura Adentro e os detalhes de cobertura, consulte nossa equipe comercial.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "O SLA de 99,99% garante que meu serviço nunca vai cair?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Não. O SLA define o limite máximo contratual de downtime e as condições de compensação caso esse limite seja ultrapassado. Não é uma garantia de zero falhas."
      }
    },
    {
      "@type": "Question",
      "name": "Downtime planejado conta para o cálculo do SLA?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Depende do contrato. A maioria dos provedores exclui manutenções notificadas com antecedência do cálculo de SLA. Leia a cláusula de exclusão antes de assinar."
      }
    },
    {
      "@type": "Question",
      "name": "Qual a diferença entre uptime e disponibilidade?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Na prática, os termos são usados como sinônimos. Tecnicamente, disponibilidade pode incluir métricas adicionais como confiabilidade e mantenabilidade (conceito RAS)."
      }
    }
  ]
}