← blog

O que é uptime: a conta do 99,9% e como medir o seu

Uptime é a porcentagem do tempo em que um sistema ficou no ar e respondendo, medida num período. Se a sua API ficou disponível em 99,9% de um mês, ela passou 43 min 48 s fora do ar nesse mês. É sempre uma medida de dois pedaços: um número (%) e uma janela (dia, mês, ano) — "99,9%" sozinho não quer dizer nada. Abaixo, a conta de cada "nove", o que a garantia de uptime do seu fornecedor realmente promete, e por que o uptime que você acha que tem só existe se alguém mede de fora.

O que é uptime e downtime

São os dois lados da mesma conta. Uptime é o tempo no ar; downtime é o tempo fora. Somados, dão 100% da janela.

uptime (%) = (tempo total − tempo fora do ar) / tempo total × 100

Um exemplo concreto: num mês de 30 dias (43.200 minutos), se a sua aplicação ficou 20 minutos fora:

(43.200 − 20) / 43.200 × 100 = 99,9537%

Duas armadilhas que aparecem muito em time pequeno:

  • "Fora do ar" precisa de definição. Timeout é downtime. Erro 500 é downtime. E o 200 que devolve página branca porque o backend caiu atrás da CDN? Pelo status code, está no ar. Pelo usuário, não. Quem só olha status code mede o uptime do nginx, não o do produto.
  • Janela diferente, número diferente. 20 minutos fora dão 99,95% no mês e 99,996% no ano. O mesmo incidente, dois números bonitos. Por isso contrato sério fixa a janela (quase sempre mês).

Quanto tempo fora do ar cabe em cada "nove"

Essa é a parte que ninguém faz de cabeça. A tabela abaixo mostra quanto downtime cada nível de uptime permite, com ano de 365 dias e mês como 1/12 do ano (a convenção das calculadoras de SLA):

Uptime Por dia Por semana Por mês Por ano
99% 14 min 24 s 1 h 40 min 48 s 7 h 18 min 3 d 15 h 36 min
99,5% 7 min 12 s 50 min 24 s 3 h 39 min 1 d 19 h 48 min
99,9% ("três noves") 1 min 26 s 10 min 5 s 43 min 48 s 8 h 45 min 36 s
99,95% 43 s 5 min 2 s 21 min 54 s 4 h 22 min 48 s
99,99% ("quatro noves") 8,6 s 1 min 4 min 23 s 52 min 34 s
99,999% ("cinco noves") 0,9 s 6 s 26 s 5 min 15 s

O que a tabela ensina na prática:

  • 99% é ruim, mesmo parecendo alto: são mais de três dias e meio fora do ar por ano.
  • 99,9% é o patamar normal de SaaS pequeno que se cuida: menos de uma hora de incidente no mês. Cabe um deploy ruim por mês, não dois.
  • Cada nove extra custa um dígito na infra. Sair de 99,9% pra 99,99% significa cortar o downtime mensal de 44 minutos pra 4: ninguém faz isso sem redundância, failover automático e deploy sem downtime. Para um time de 3 pessoas, prometer quatro noves é prometer o que não se controla.
  • Manutenção programada normalmente fica fora da conta dos contratos. Se o seu fornecedor derruba a API 2 h num domingo e avisou antes, o SLA dele continua intacto — e o seu cliente, que não leu o aviso, continua achando que caiu.

Para fazer a conta com o seu número (inclusive ao contrário: "ficamos 37 minutos fora, que uptime é esse?"), a calculadora de uptime e SLA resolve no navegador.

O que é uptime do servidor (e por que o comando uptime não responde isso)

Aqui mora uma confusão que vale desfazer, porque são três coisas diferentes com o mesmo nome:

O que é O que mede Quem usa
uptime (comando Linux) há quanto tempo a máquina está ligada sem reiniciar sysadmin, no SSH
Uptime do servidor/hospedagem % do tempo em que o servidor respondeu contrato do provedor
Uptime da aplicação % do tempo em que o seu serviço respondeu certo quem tem cliente

O comando do Linux é o mais mal entendido. Rodando no terminal:

$ uptime
 14:02:11 up 97 days,  3:41,  2 users,  load average: 0.21, 0.19, 0.14

Isso diz que a máquina não reinicia há 97 dias. Não diz nada sobre a sua aplicação: o processo pode ter morrido há duas horas, o banco pode estar recusando conexão, e o uptime continua marcando 97 dias com orgulho. Em infra moderna (container que recicla, serverless que nem tem máquina fixa) esse número perdeu quase todo o sentido.

E uptime da hospedagem não é o uptime do seu produto. O provedor pode cumprir 99,99% de servidor no ar enquanto a sua aplicação passou duas horas devolvendo 500 por causa de uma migração travada. Para o seu cliente, o produto ficou fora do ar duas horas. Os dois números são verdadeiros e medem coisas diferentes — só o segundo importa pra quem vende software.

O que é garantia de uptime (e a letra miúda do SLA)

Garantia de uptime é o compromisso contratual de um fornecedor com um uptime mínimo numa janela, com uma compensação definida caso ele não entregue. Três coisas que quase todo contrato tem e quase ninguém lê:

  1. A compensação é crédito, não dinheiro de volta. No SLA de computação da AWS (versão de 25/05/2022, consultada em 28/10/2026), instâncias EC2 rodando em duas ou mais zonas da mesma região têm compromisso de 99,99% mensal. Se cair abaixo disso e ficar em 99,0% ou mais, o crédito é de 10% da fatura; abaixo de 99,0%, 30%; abaixo de 95%, 100%. Crédito em serviço, para usar depois.
  2. Você tem que pedir. O mesmo documento exige abrir um caso no AWS Support Center, com prazo: o pedido precisa chegar até o fim do segundo ciclo de faturamento após o incidente. Quem não reclama não recebe.
  3. O cálculo é do fornecedor. Ele mede, ele decide o que conta como indisponibilidade, ele aplica as exclusões (manutenção programada, problema de rede do cliente, erro na sua configuração).

Tradução prática: garantia de uptime é instrumento de contrato, não de confiabilidade. Ela não impede a queda, não avisa você e, no melhor caso, devolve uma fração da fatura daquele mês. O que protege o seu cliente é você saber da queda antes dele.

O que é monitoramento de uptime: só sabe quem mede de fora

Monitoramento de uptime é fazer requisições periódicas ao seu serviço a partir de uma máquina fora da sua infraestrutura e registrar se a resposta veio, veio no prazo e veio certa. É isso que transforma "acho que está de boa" em número.

Tem que ser de fora por um motivo bobo e definitivo: um monitor que roda na mesma máquina (ou na mesma VPS, ou na mesma conta de cloud) cai junto com o que ele deveria vigiar. Quando mais precisa dele, ele está morto. Health check interno serve pro orquestrador reiniciar container; não serve pra medir uptime.

Um monitoramento que presta checa quatro coisas, não uma:

  • Resposta chegou? Timeout e conexão recusada são falha.
  • Status code está certo? 2xx e 3xx ok; 5xx é falha. 4xx depende do endpoint.
  • O conteúdo bate? Procurar uma palavra no corpo (o nome do produto, um "status":"ok") pega o caso do 200 com página branca.
  • Demorou quanto? Resposta de 15 s não é "no ar" na prática.

A dica que vale mais que a escolha da ferramenta: aponte o monitor pra um endpoint de health (https://api.suaempresa.com.br/health) que toque de leve as dependências críticas (banco, fila), em vez da home. A home passa por CDN e pode responder 200 cacheado com o backend inteiro no chão.

Uptime medido por amostra: o intervalo de checagem muda o número

Esta parte é a que quase nenhum texto em português conta: o uptime que qualquer ferramenta te mostra é estimativa por amostragem, não medição contínua. Ela checa de 5 em 5 minutos, de 1 em 1 minuto, e calcula a porcentagem a partir dos checks que deram certo sobre o total de checks.

As consequências são bem concretas:

  • Checagem de 5 minutos pode perder uma queda de 3 minutos inteira. Ela aconteceu, o cliente viu, e o seu relatório diz 100%.
  • A resolução do número é o intervalo. Com check de 5 min, cada falha pesa ~5 minutos de downtime no mês. Medir 99,99% com amostra de 5 minutos é precisão fingida: um único check falho já derruba o mês pra baixo de 99,99%.
  • Menos intervalo = menos cegueira. É por isso que ferramenta cobra por intervalo curto: 1 minuto não é luxo, é a diferença entre detectar e não detectar incidente curto.
  • Sem check, não existe uptime. Monitor criado agora não tem 100%: tem "sem dados". É a diferença entre "medimos e estava no ar" e "ninguém olhou".

No Tá Rodando, por exemplo, o uptime de cada serviço na status page é exatamente isso: checks com sucesso dividido pelo total de checks na janela de 90 dias — e monitor que nunca rodou aparece como "sem dados", nunca como 100% verde. No plano grátis são 10 monitores a cada 5 minutos; a checagem de 1 minuto é do Pro (R$ 79/mês). O alerta de caiu/voltou sai na primeira falha, pro Telegram, Discord, Slack ou Google Chat do time.

Se você quer comparar quem mede o quê, o UptimeRobot e o Better Stack estão destrinchados em posts próprios, com preço e canais das páginas oficiais.

Perguntas rápidas

O que é uptime em TI? É a porcentagem de tempo em que um sistema (site, API, servidor, serviço) ficou disponível numa janela de tempo. Em TI o termo aparece em dois lugares: no contrato, como garantia do fornecedor, e no monitoramento, como número medido. Em infra, "uptime" ainda pode significar o tempo desde o último reboot da máquina — outra coisa.

Como calcular o uptime? Divida o tempo no ar pelo tempo total da janela e multiplique por 100. Numa janela de 30 dias (43.200 minutos) com 20 minutos fora: (43200 − 20) / 43200 × 100 = 99,95%. Ferramenta de monitoramento faz a conta por checks: checks bem-sucedidos ÷ total de checks.

Qual é um bom uptime? Para SaaS pequeno, 99,9% no mês (até 43 min 48 s fora) é um alvo honesto e alcançável. 99,99% exige redundância e deploy sem downtime: não prometa o que a sua infra não entrega, porque o número vira dívida contratual.

Qual a diferença entre uptime e disponibilidade? No uso diário, nenhuma — "disponibilidade" é a tradução usual de availability, e é o termo dos contratos. Rigorosamente, disponibilidade inclui responder de forma útil (sem erro, no prazo), enquanto "uptime" às vezes é usado só para "ligado". Na prática, meça disponibilidade e chame de uptime.

O que é uptime de 99,9% em minutos? 43 min 48 s por mês, 10 min 5 s por semana e 8 h 45 min 36 s por ano.

O seu uptime real só existe depois que alguém mede. Cole a URL, escolha o canal onde o time conversa, e o primeiro número aparece na mesma hora.

Criar status page grátis