O que é uptime e porque importa
· 5 min de leitura
Uptime é a percentagem de tempo em que o site está acessível. 99% são mais de três dias de falha por ano; o alvo realista é 99,9% e saber em minutos.
Definição: o que medimos exatamente
Uptime é a relação entre o tempo em que o serviço responde como esperado (tipicamente HTTP 200, conteúdo com palavra-chave) e o tempo total de medição. Expresso em percentagem, mais comumente para períodos de 30 ou 365 dias.
O oposto é o downtime - o tempo em que o serviço não responde, devolve 5xx ou demora mais que o timeout definido. Inclui também a manutenção programada, a menos que a excluas explicitamente do cálculo (o que deves comunicar no SLA).
Tabela dos "noves": quanto tempo significa cada casa decimal
| Uptime | Downtime permitido / ano | Mês | Dia |
|---|---|---|---|
| 99 % | 3 dias 15 h | 7 h 18 min | 14 min |
| 99,5 % | 1 dia 19 h | 3 h 39 min | 7 min |
| 99,9 % (three nines) | 8 h 45 min | 43 min | 1 min 26 s |
| 99,95 % | 4 h 22 min | 21 min | 43 s |
| 99,99 % (four nines) | 52 min | 4 min 22 s | 8,6 s |
| 99,999 % (five nines) | 5 min 15 s | 26 s | 0,86 s |
Cada nove adicional multiplica os custos de infraestrutura. Five nines (99,999 %) é o domínio dos fornecedores globais com redundância ativa intercontinental - para a maioria das aplicações de negócio, 99,9 % é o objetivo certo.
Que uptime precisas realmente
- Site marketing (empresa, portefólio): 99 % chega. Um visitante que chega durante uma queda tenta de novo mais tarde.
- App SaaS com cliente desktop: 99,9 % é o mínimo. Os clientes pagam por trabalho que não conseguem fazer durante o downtime.
- E-commerce, gateway de pagamento, serviço real-time: 99,95 % e acima. Cada minuto = perdas diretas.
- Infraestrutura (API usada por outros): Pelo menos 99,99 %. O teu SLA limita o SLA dos clientes.
Como o uptime é medido
O serviço de monitorização chama periodicamente o teu endpoint (tipicamente HTTP GET, mas também socket TCP, ping ICMP ou resolução DNS). Cada verificação tem um resultado binário: up ou down.
Um intervalo comum são 1-5 minutos. Quanto mais curto, mais depressa apanhas uma queda, mas mais alertas falso-positivos recebes (um glitch local de rede, um breve reinício por deploy). A solução é a verificação multi-região: uma queda só se confirma quando N regiões a reportam, não apenas uma.
Fontes mais comuns de "noves perdidos"
- Certificado SSL/TLS expirado. O browser bloqueia a página. Sem monitorização sabes à segunda-feira de manhã quando toca o telefone.
- Expiração do domínio. Todo o DNS deixa de funcionar. Email, web e status page - tudo cai ao mesmo tempo.
- Worker de base de dados em crash. O site devolve 500 ou entra em timeout para parte dos requests. Um ping clássico até pode passar, ainda que a aplicação esteja partida.
- DDoS ou flooding. O servidor fica sobrecarregado, o tempo de resposta sobe acima do limite e a monitorização reporta uma queda.
- Deploy mal feito. Uma nova versão tem um bug que parte algum caminho. Sem testes de integração só descobres quando os clientes começam a queixar-se.
Conclusão
O uptime não é um número de marketing - é a medida de quanto podes confiar na tua própria infraestrutura. 99,9 % de uptime não é luxo, é um requisito padrão para qualquer serviço que gera faturação ou tem clientes pagantes.
O passo um é medir. Se não tens monitorização externa, tecnicamente não sabes que uptime tens - só o estimas.
Começa a medir o uptime dos teus serviços
O ePulz.io segue os teus endpoints em intervalos a partir de 1 minuto de várias regiões. 7 dias grátis.
Experimente o ePulz.io grátis - 7 dias sem cartão de crédito.
Criar conta