2026-07-17 · Atualizado em 2026-10-26
98% de uptime é bom? São 7,3 dias de inatividade por ano
- sla
- uptime
- confiabilidade
- tempo-de-inatividade
Resumo. Para um site público ou uma API paga, não. 98% de uptime permite 7,3 dias de inatividade por ano, ou 14,4 horas todo mês. Para uma wiki interna ou um projeto paralelo, tudo bem. A maioria dos serviços voltados a clientes mira 99,9%, que permite 43 minutos por mês. A tabela completa de inatividade está logo abaixo, e a calculadora de SLA de uptime faz a conta para qualquer meta.
Todo o trabalho de uma meta de uptime é manter esta placa acesa. Foto de the blowup no Unsplash.
98% parece nota de aluno exemplar. Na escola, é mesmo. Só que uptime não se avalia como na escola: a escala inteira dos serviços públicos fica entre 99% e 100%, e as metas sérias só diferem nos dígitos depois da vírgula. Nessa escala, 98% fica lá embaixo.
O truque para ler qualquer número de uptime é converter a porcentagem em tempo. A falha permitida com 98% é de 2%. Dois por cento de um ano são 7,3 dias. Dois por cento de um mês de 30 dias são 14,4 horas. Se a sua loja fatura US$ 2.000 por dia, 98% de uptime significa que você aceita cerca de US$ 14.600 por ano de portas fechadas, e a meta continua contando como cumprida.
A tabela de inatividade
Multiplique a janela pela falha permitida e as porcentagens param de esconder o jogo. A última coluna põe preço na inatividade daquela loja de US$ 2.000 por dia.
| Uptime | Por dia | Por mês de 30 dias | Por ano | Vendas perdidas por ano |
|---|---|---|---|---|
| 90% | 2,4 horas | 3 dias | 36,5 dias | US$ 73.000 |
| 95% | 1,2 hora | 36 horas | 18,3 dias | US$ 36.500 |
| 98% | 28,8 minutos | 14,4 horas | 7,3 dias | US$ 14.600 |
| 99% | 14,4 minutos | 7,2 horas | 3,7 dias | US$ 7.300 |
| 99,5% | 7,2 minutos | 3,6 horas | 1,8 dia | US$ 3.650 |
| 99,9% | 1,4 minuto | 43 minutos | 8,8 horas | US$ 730 |
| 99,95% | 43 segundos | 21,6 minutos | 4,4 horas | US$ 365 |
| 99,99% | 8,6 segundos | 4,3 minutos | 52,6 minutos | US$ 73 |
| 99,999% | 0,9 segundo | 26 segundos | 5,3 minutos | US$ 7 |
Dois saltos nesta tabela fazem a maior parte do trabalho nos contratos reais. De 98% para 99,9%, a inatividade permitida cai de 14,4 horas por mês para 43 minutos. De 99,9% para 99,99%, cai de 43 minutos para 4,3 minutos, e esse último salto costuma ser o caro.
A coluna do dinheiro deixa a troca clara. O primeiro salto vale cerca de US$ 13.900 por ano para a loja. O segundo vale US$ 657 e custa muito mais engenharia do que o primeiro. Os noves extras só se pagam quando o valor por dia é muito maior do que US$ 2.000.
Quando 98% basta
Muitos sistemas podem viver com 98% sem prejudicar ninguém:
- Uma wiki interna. As pessoas tentam de novo depois do almoço.
- Um ambiente de staging. Ali, a inatividade muitas vezes é planejada.
- Um job em lote que gera relatórios à noite. Ele tem horas de folga antes de alguém ler o resultado.
- Um servidor caseiro numa conexão residencial. A sua companhia de energia já decidiu o seu uptime por você.
O padrão em comum: quando esses sistemas caem, ninguém perde dinheiro e ninguém perde a confiança. Pagar por mais noves ali é desperdício. Se você nunca gasta o seu orçamento de inatividade, a sua meta está rígida demais, que é a mesma regra que rege os orçamentos de erros.
Quando não basta
Uma página de checkout, uma API paga, um serviço de login. Aqui, 98% falha duas vezes.
Primeiro, o custo direto: 14,4 horas por mês de requisições com falha, pagamentos perdidos e chamados de suporte.
Segundo, o custo de confiança, que é maior e mais lento. Um cliente que dá de cara com a sua queda duas vezes na mesma semana não vai conferir o seu relatório de uptime. Ele lembra que o seu serviço é o que quebra.
Há também um problema de contrato. Se os seus clientes têm SLAs próprios, os seus 98% viram o teto deles. Ninguém consegue construir um serviço de 99,9% em cima de uma dependência de 98% sem engenharia extra para contorná-la.
O formato da inatividade importa
98% num mês são 14,4 horas, mas o número não diz nada sobre como essas horas se distribuem.
Em um mês de 30 dias, 28,8 minutos de manutenção planejada toda noite às 03:00 somam 98%, e a maioria dos usuários nunca percebe. Uma única queda de 14,4 horas no dia do lançamento do seu produto também dá 98%. Mesmo número, mês muito diferente.
Por isso, uma única porcentagem de uptime é um resumo, não a história completa. Você também quer saber qual foi a queda mais longa e quando ela aconteceu. Um mês de 98% feito de pequenas falhas noturnas é um serviço que funciona, com uma janela de manutenção. Um mês de 98% feito de uma única queda longa durante o dia é um incidente com um relatório para escrever.
Uptime é medido, SLA é prometido
Os dois vivem sendo confundidos. Uptime é uma medição: a fração do tempo em que o seu serviço de fato respondeu. Um SLA é uma promessa em contrato, com uma penalidade definida para quando é descumprido.
A penalidade quase sempre é um crédito de serviço. Se um provedor descumpre o SLA de 99,9%, você recebe de volta uma porcentagem da fatura daquele mês. Os seus clientes não recebem nada, porque o crédito reembolsa a sua fatura, não o tempo deles. Então um SLA mostra o quanto o provedor está confiante e põe um teto no seu reembolso. Ele não mantém o seu serviço no ar.
A regra prática: prometa um número que você mediu, não um número que soa bem. Se você nunca mediu o seu uptime, não sabe se está em 98% ou em 99,9%, e a distância entre os dois é de 13,7 horas por mês.
Que meta buscar em vez disso
99,9% não é por acaso a meta padrão dos serviços voltados a clientes. 43 minutos por mês dão margem para um deploy ruim e algumas falhas pequenas, e uma equipe pequena consegue chegar lá sem heroísmo. Acima disso, cada nove custa cerca de dez vezes mais engenharia, e a maioria dos usuários não sente a diferença.
Escolha a meta na tabela e depois meça o serviço contra ela. A parte da medição é o que o monitoramento de uptime externo faz: ele verifica o seu serviço de fora, do jeito que um usuário chega até ele, e registra cada falha, esteja você olhando ou não. O número medido só continua honesto se a sua página de status o mostra diretamente, que é a ideia por trás de uma página de status que não dá para falsificar.
Cada uma das metas comuns tem o próprio detalhamento: 99,9% permite 43 minutos e 12 segundos por mês, 99,95% permite 21 minutos e 36 segundos e 99,99% permite 4 minutos e 19 segundos.
Faça as suas próprias contas na calculadora de SLA de uptime, ou descubra com que rapidez uma queda gasta o seu orçamento na calculadora de orçamento de erros. Se a coluna de inatividade ao lado da sua meta atual surpreende você, é sinal de que você escolheu uma porcentagem, e não uma promessa.
Perguntas frequentes
Quanto tempo de inatividade 98% de uptime permite?
98% de uptime permite 28,8 minutos de inatividade por dia, 14,4 horas por mês de 30 dias ou 7,3 dias por ano. A falha permitida é 2% da janela de tempo, então multiplique qualquer janela por 0,02 para chegar ao número.
98% de uptime é bom para um site?
Não para um site público nem para uma API pela qual os clientes pagam. 98% permite 14,4 horas de inatividade por mês. Serve para ferramentas internas, servidores de staging e projetos pessoais, em que ninguém perde dinheiro enquanto eles estão fora do ar.
Qual uptime devo ter como meta?
99,9% é a meta comum para serviços voltados a clientes. Ela permite 43 minutos de inatividade por mês de 30 dias, o que dá margem suficiente para deploys e pequenas falhas. Cada nove a mais custa cerca de dez vezes mais engenharia.
Qual é a diferença entre uptime e SLA?
Uptime é o número medido: quanto do tempo o seu serviço de fato funcionou. Um SLA é uma promessa em contrato com uma penalidade, geralmente um crédito de serviço na sua fatura. Um provedor pode prometer 99,9% no SLA e ainda assim entregar 98%. O crédito devolve parte da fatura. Ele não devolve o tempo dos seus clientes.