SLA de Hospedagem: Uptime e Janela de Manutenção Explicados

O SLA de hospedagem é o trecho do contrato que diz quanto tempo o seu site ou sistema pode ficar fora do ar sem que o fornecedor deva nada a você. Parece detalhe jurídico, mas é ele que decide se a queda de uma terça-feira à tarde vira crédito, multa ou só um pedido de desculpas por e-mail. Neste guia eu explico, em português claro, uptime, SLA e janela de manutenção, com números reais e as letras miúdas que mais pegam o cliente.

TL;DR

• 99,9% de uptime permite cerca de 43 minutos de queda por mês. 99,5% permite 3 horas e 36 minutos. A diferença de um "nove" é enorme.
• O SLA de hospedagem quase nunca paga o seu prejuízo: ele devolve um percentual da mensalidade em crédito. Na AWS, uma instância EC2 que cai abaixo de 99,5% rende 10% de crédito.
• Manutenção programada costuma ficar fora da conta do uptime. Leia como o contrato define a janela e com quanta antecedência ela é avisada.
• Um sistema depende de vários serviços. Três componentes de 99,9% em série entregam cerca de 99,7% no total.
• O que mais importa, além do percentual: tempo de resposta, tempo de resolução e tempo de restauração de backup escritos no contrato.

O que é SLA de hospedagem (e o que ele não é)

SLA é a sigla de Service Level Agreement, o acordo de nível de serviço. No SLA de hospedagem, o contrato formaliza três coisas: qual métrica o fornecedor promete (normalmente o uptime mensal), como essa métrica é medida e o que acontece quando ela não é cumprida.

No dia a dia de quem opera servidor, três siglas aparecem juntas:

• SLI (indicator): o número medido de fato. Exemplo: o site respondeu 99,94% das checagens no mês.
• SLO (objective): a meta interna da equipe. Exemplo: queremos 99,95%.
• SLA (agreement): a promessa contratual, normalmente mais folgada que o SLO, porque descumpri-la custa dinheiro.

Uptime e disponibilidade não são exatamente a mesma coisa

Uptime é o percentual do tempo em que o serviço esteve no ar. Disponibilidade, no sentido mais rigoroso, é o percentual do tempo em que ele estava utilizável para o usuário. Um servidor pode estar ligado, com o ping respondendo, enquanto o banco de dados travou e a página devolve erro 500. Para o fornecedor de infraestrutura, isso pode contar como uptime. Para o seu cliente, o site caiu.

Por isso a primeira pergunta ao ler um SLA de hospedagem é: o que exatamente está sendo medido? O servidor? A rede? A resposta HTTP da sua aplicação?

O SLA não é uma garantia de que nada vai cair

Este é o equívoco mais comum sobre o SLA de hospedagem em contratos de pequenas e médias empresas. Um SLA de hospedagem de 99,9% não diz que o site não vai cair. Ele diz quanto de queda o fornecedor considera aceitável e qual compensação oferece se passar disso. Quem compra hospedagem achando que o SLA é um seguro contra prejuízo se decepciona na primeira queda séria.

Quanto tempo fora do ar cada "nove" permite

O jeito mais honesto de comparar um SLA de hospedagem com outro é converter o percentual em minutos. A conta abaixo usa um mês de 30 dias (43.200 minutos) e um ano de 365 dias:

Uptime prometido	Queda permitida por mês	Queda permitida por ano
99%	7 h 12 min	3 dias e 15 h 36 min
99,5%	3 h 36 min	1 dia e 19 h 48 min
99,9%	43 min 12 s	8 h 45 min 36 s
99,95%	21 min 36 s	4 h 22 min 48 s
99,99%	4 min 19 s	52 min 34 s

Repare no salto. Sair de 99,5% para 99,9% corta a queda tolerada de mais de três horas e meia para menos de 45 minutos por mês. Já de 99,9% para 99,99% a diferença é de 43 minutos para 4, e esse último nove é o mais caro de todos, porque exige redundância de verdade.

Um exemplo prático com Moodle

Pense em um AVA Moodle com prova on-line marcada para as 19h. Um contrato de 99,5% permite que o ambiente fique fora 3 horas e meia naquele mês sem nenhuma violação. Se essas 3 horas caírem exatamente na janela da prova, o fornecedor cumpriu o SLA e a instituição terá de remarcar a avaliação, atender reclamação de aluno e explicar o problema à coordenação. Nos ambientes Moodle que administramos, é por isso que olhamos primeiro quando a queda pode acontecer, e não só quanto.

Como ler um SLA de hospedagem: as cláusulas que importam

Antes de assinar qualquer SLA de hospedagem, procure estes pontos no contrato. Se algum deles não estiver escrito no SLA de hospedagem que você recebeu, ele não existe.

1. Métrica e forma de medição. Quem mede? O próprio fornecedor ou uma ferramenta externa? Em que intervalo? Uma checagem a cada 5 minutos não enxerga quedas de 3 minutos.
2. Período de apuração. Mensal é o padrão. SLA anual dilui uma queda grande em doze meses e quase nunca dispara compensação.
3. Exclusões. Força maior, ataques DDoS, falha de terceiros, erro do próprio cliente e manutenção programada aparecem em quase todo contrato. O problema é quando a lista é tão ampla que sobra pouca coisa coberta.
4. Definição de manutenção programada. Com quanta antecedência ela é avisada? Qual a duração máxima? Em que horário? Sem limite escrito, toda queda pode virar manutenção.
5. Compensação. Crédito na fatura, desconto ou multa? Qual o teto? Ela é automática ou precisa ser pedida?
6. Prazo para reclamar. Alguns fornecedores exigem que o cliente abra chamado em poucos dias ou no mês seguinte. Perdeu o prazo, perdeu o crédito.
7. Tempo de resposta e de resolução por severidade. Esta é a cláusula que mais faz diferença na prática, e a que mais falta nos planos de prateleira.
8. Backup e restauração. Com que frequência o backup é feito (o RPO, ou quanto dado você aceita perder) e em quanto tempo o ambiente volta (o RTO, ou quanto tempo você aceita ficar parado).

Exemplo real de cláusula de compensação

A central de ajuda da Locaweb informa SLA mensal de 99,5% para os planos de hospedagem compartilhada, com desconto escalonado: 5% quando a disponibilidade fica entre 99,0% e 99,4%, 10% entre 95,0% e 98,9%, 20% entre 90,0% e 94,9% e 30% abaixo de 89,9%. E o cliente precisa solicitar a apuração por chamado, no início do mês seguinte. É um modelo transparente e comum no mercado, e mostra bem a lógica: a compensação é proporcional à mensalidade, não ao estrago.

Crédito de serviço: por que o SLA não paga o seu prejuízo

Veja como o SLA de hospedagem funciona no maior provedor de nuvem do mundo. O SLA do Amazon EC2 tem dois níveis:

• Por instância: 99,5% de uptime mensal. Abaixo disso e até 99,0%, o crédito é de 10%. Entre 99,0% e 95,0%, 30%. Abaixo de 95%, 100%.
• Por região: 99,99%, mas só para quem distribui instâncias em duas ou mais zonas de disponibilidade da mesma região.

Traduzindo: uma única máquina na AWS, sozinha, tem promessa de 99,5%, a mesma faixa de uma hospedagem compartilhada. O 99,99% só existe quando você paga por redundância. E o que você recebe é crédito em cima da conta daquela instância.

Agora compare com o custo de ficar parado. O relatório anual de quedas do Uptime Institute de 2025 aponta que 54% dos entrevistados disseram que a última queda significativa custou mais de US$ 100 mil, e 20% relataram custo acima de US$ 1 milhão. A empresa média brasileira não está nessa escala, mas a proporção vale: se o servidor custa R$ 300 por mês, o crédito máximo de 10% é R$ 30. Uma tarde de e-commerce parado, um dia de matrícula fora do ar ou um atendimento no WhatsApp sem resposta custam muito mais que isso.

Conclusão prática: o crédito previsto no SLA de hospedagem é um incentivo para o fornecedor, não um seguro para você. O que protege o seu negócio é a arquitetura (redundância, backup testado, monitoramento) e a equipe que responde quando algo dá errado. É exatamente essa camada que uma hospedagem gerenciada com SLA contratual cobre e uma VPS sozinha não cobre.

Janela de manutenção: quando fazer e quando não fazer

No SLA de hospedagem, a janela de manutenção é o período combinado em que o fornecedor pode atualizar sistema operacional, PHP, banco de dados, kernel ou hardware, com risco de indisponibilidade. Ela é necessária: servidor sem atualização é servidor vulnerável. O problema é quando ela é usada como desculpa.

Quando fazer

• No horário de menor tráfego real do seu público, e não no horário que é conveniente para o fornecedor. Para a maioria dos sites brasileiros é a madrugada de domingo para segunda, mas um AVA de pós-graduação noturna ou um e-commerce que vende para Portugal tem outro desenho. Olhe o gráfico de acessos antes de escolher.
• Com staging antes. Atualização de PHP ou de banco testada em cópia do ambiente reduz o tempo de janela de horas para minutos.
• Com aviso prévio. Em ambientes que administramos, a regra é avisar com antecedência, informar duração estimada e o plano de reversão.
• Com patch crítico de segurança. Quando sai uma CVE grave e explorada, a janela pode precisar ser antecipada. Aqui a velocidade vale mais que o horário perfeito.

Quando NÃO fazer

• Semana de prova ou de matrícula em instituições de ensino. No Moodle, congelamos atualizações não urgentes nesses períodos.
• Black Friday, lançamentos e campanhas pagas no ar. Mexer em infraestrutura com tráfego comprado chegando é queimar verba.
• Fechamento de mês para ERP, sistemas financeiros e emissão de nota.
• Sexta à tarde. Se a atualização der errado, a equipe precisa estar descansada e disponível para reverter, e não começando o fim de semana.

O Moodle ajuda: modo de manutenção

No Moodle, ative o modo de manutenção antes de atualizar. Ele exibe uma mensagem para alunos e mantém o acesso dos administradores. Parece óbvio, mas já recebemos ambiente de outro fornecedor em que a atualização era feita com o AVA aberto, aluno no meio de questionário. Se a mudança envolve trocar de servidor, o cuidado é maior; detalhei o processo em como migrar o Moodle de servidor sem perder dados.

SLA composto: a corrente é tão forte quanto o elo mais fraco

Seu sistema raramente depende de um serviço só. Um site típico passa por DNS, CDN, servidor web, banco de dados, serviço de e-mail transacional e, cada vez mais, APIs de terceiros. Quando esses componentes estão em série (se um cai, tudo cai), as disponibilidades se multiplicam:

• 99,9% × 99,9% × 99,9% = 99,7%, ou cerca de 2 horas e 10 minutos de queda tolerada por mês.
• Com cinco componentes de 99,9%, o resultado cai para cerca de 99,5%.

Na prática, isso significa que o SLA de hospedagem do servidor não é o SLA do seu negócio. Um exemplo que vivemos em integrações com a API oficial do WhatsApp: o servidor pode estar 100% no ar e, mesmo assim, o atendimento parar porque a Meta teve instabilidade, porque o token expirou ou porque o webhook ficou sem resposta. Um bom desenho de infraestrutura trata esses pontos com fila, nova tentativa automática e alerta, para que uma falha externa não derrube o resto.

Como subir a disponibilidade sem multiplicar o custo

• Coloque redundância só onde dói. Banco de dados com réplica e failover costuma ser o maior ganho por real investido.
• Use CDN na frente. Um CDN serve páginas em cache mesmo durante uma queda curta da origem. O SLA Business da Cloudflare, por exemplo, promete 100% de uptime para clientes do plano Business.
• Monitore de fora. A medição tem que vir de um ponto externo ao seu servidor; senão, quando ele cai, o monitor cai junto.

Armadilhas comuns no SLA de hospedagem

Estas são as que mais encontro ao revisar o SLA de hospedagem de clientes que chegam de outro fornecedor:

• "Uptime de rede" vendido como uptime do site. O link estava no ar; o seu WordPress, não. Leia o que é medido.
• Manutenção sem teto. Contrato que exclui manutenção programada sem limitar duração nem exigir aviso. Na prática, qualquer queda pode ser reclassificada.
• Compensação que exige chamado com prazo curto. Você só descobre que tinha direito quando o prazo passou.
• Suporte sem tempo de resolução. "Resposta em 15 minutos" que significa um robô dizendo que recebeu o chamado.
• Backup sem teste de restauração. O backup existe, mas ninguém nunca restaurou. No dia da necessidade, o arquivo está corrompido ou incompleto.
• SLA que não cobre o seu código. Plugin desatualizado, consulta lenta no banco ou erro de deploy derrubam o site, e nada disso é responsabilidade do fornecedor de infraestrutura pura.
• Fidelidade longa com SLA fraco. Se o serviço não entrega, você não consegue sair sem multa.

Boa parte dessas armadilhas some quando fica claro quem cuida de quê. Fiz uma comparação direta em hospedagem gerenciada vs VPS: quem cuida do quê quando o site cai. E, como queda por invasão também é queda, vale revisar o checklist de hardening de servidor Linux.

Quanto custa subir um nove (e quando não vale a pena)

Cada nove adicional no SLA de hospedagem custa mais que o anterior. A régua aproximada que usamos ao conversar com clientes:

Meta	O que normalmente exige	Para quem faz sentido
99,5%	Servidor único, backup diário, monitoramento básico	Site institucional, blog, landing page
99,9%	Servidor bem dimensionado, CDN, monitoramento 24/7, equipe on-call, patches em janela	E-commerce pequeno, AVA Moodle, sistemas internos
99,95%	Banco com réplica e failover, deploy sem downtime	SaaS, ERP, operação que vende ou atende o dia todo
99,99%	Múltiplas zonas, balanceamento, failover automático testado	Operação em que minutos parados custam muito

Quando NÃO vale a pena pagar por mais um nove

• Quando o tráfego é comercial e o público não usa o sistema de madrugada. Uma queda às 4h de domingo não aparece para ninguém.
• Quando o gargalo é a aplicação. Se o seu sistema cai por código ou plugin, redundância de servidor só duplica o problema.
• Quando o custo da queda é menor que o da redundância. Faça a conta: quanto você perde por hora parado? Multiplique pelas horas extras toleradas no nível atual. Se der menos que a diferença de mensalidade, o nove extra é luxo.

Antes de pagar por 99,99% no SLA de hospedagem do seu servidor, quase sempre vale mais garantir tempo de resposta curto e backup testado. Na maioria das quedas que atendemos, o que define o estrago não é o percentual do contrato, e sim quantos minutos a equipe leva para perceber e agir.

Como a Agathas Web resolve isso

Operamos servidores Linux, ambientes Moodle e sistemas sob medida desde 2008. A nossa hospedagem gerenciada tem um SLA de hospedagem que responde às perguntas deste guia por escrito, no contrato:

• Uptime mensal de 99,9% (até cerca de 43 minutos por mês), medido por monitoramento externo 24/7.
• Resposta a incidente crítico em até 15 minutos e resolução em até 2 horas, com runbook por tipo de incidente.
• Backup diário mais incremental, criptografado e fora do servidor, com restauração testada todo mês e restauração das últimas 24 horas em até 4 horas.
• Patch crítico em até 72 horas após CVE pública, sempre passando por staging e em janela de manutenção combinada com você, respeitando semana de prova, campanha e fechamento.
• Multa contratual se descumprirmos o SLA, e relatório mensal com uptime, incidentes e backups testados.
• Sem fidelidade: contrato mensal com 30 dias de aviso.

Na prática, o atendimento é feito por quem opera o ambiente, com canal direto no WhatsApp. Para contratar, você pede um diagnóstico gratuito da infraestrutura atual: analisamos o contrato e a arquitetura que você tem hoje, apontamos riscos e, se fizer sentido, migramos em até 7 dias úteis, com staging, janela de baixo tráfego e plano de reversão. Se o seu caso é um AVA, a página de hospedagem Moodle tem os detalhes específicos.

Conclusão: pergunte em minutos, não em percentuais

O SLA de hospedagem só é útil quando você o traduz em minutos, cláusulas e responsáveis. Converta o percentual em tempo de queda, descubra o que é medido, veja como a manutenção programada é tratada e, principalmente, quanto tempo a equipe leva para responder e restaurar. O crédito na fatura é o menor dos benefícios; o que protege o negócio é arquitetura bem feita e gente acordada quando o alerta toca.

Se você quer um contrato em que esses números estejam escritos, com multa se não forem cumpridos, conheça a hospedagem gerenciada da Agathas Web e peça o diagnóstico gratuito do seu ambiente.