Como interpretar um SLA de hospedagem: 10 cláusulas essenciais antes de contratar

SLA de hospedagem é o acordo de nível de serviço que define, por escrito, o que o provedor se compromete a entregar e como eventuais falhas serão tratadas. Ao interpretar um SLA de hospedagem, você não deve olhar apenas para a promessa de disponibilidade. É preciso entender métricas, exceções, canais de suporte, responsabilidades e compensações previstas no contrato.

Para uma pequena empresa, a indisponibilidade de um site pode interromper formulários, contatos pelo WhatsApp, vendas e campanhas de Google Ads. Um consultório pode deixar de receber solicitações de agendamento, enquanto um escritório pode transmitir uma percepção de descuido justamente quando um potencial cliente está pesquisando seus serviços.

O SLA transforma expectativas genéricas em critérios verificáveis. Sem ele, frases como “servidor estável” ou “suporte rápido” ficam abertas a interpretações, porque não informam qual é o prazo de resposta, como o tempo de indisponibilidade será medido ou o que acontece durante uma manutenção programada.

Também é necessário separar SLA de contrato comercial. O contrato trata de preço, prazo, renovação e cancelamento; o SLA detalha a operação do serviço. Os dois documentos devem ser lidos juntos, incluindo anexos, políticas de uso aceitável, regras de backup e condições para solicitar créditos.

Antes de avaliar um fornecedor, faça um inventário simples: endereço do site, plataforma utilizada, volume aproximado de acessos, e-mails profissionais, integrações, formulários e períodos de maior demanda. Esse contexto ajuda a verificar se a promessa contratual atende a uma operação real, e não apenas a uma página institucional básica.

A orientação para escolher uma hospedagem de sites para sua empresa complementa esta análise com critérios de desempenho, suporte e estrutura. Aqui, o foco é compreender o documento que formaliza essas expectativas.

Percentuais de uptime precisam ser convertidos em tempo para fazer sentido. Em um mês de 30 dias, 99% representa até 7 horas e 12 minutos de indisponibilidade; 99,9% representa cerca de 43 minutos e 12 segundos; 99,99% representa aproximadamente 4 minutos e 19 segundos. Esses valores são referências matemáticas, não uma promessa sobre qualquer contrato específico.

A conta, porém, não basta. Pergunte se o cálculo é mensal, trimestral ou anual, se considera cada domínio individualmente e se existe arredondamento. Um SLA anual pode esconder um problema recorrente em um mês crítico, enquanto uma medição mensal permite identificar rapidamente uma degradação operacional.

Tempo de resposta e tempo de solução são métricas diferentes. Se um chamado crítico recebe uma confirmação em 20 minutos, mas só é resolvido depois de 14 horas, o suporte pode ter cumprido a primeira obrigação e falhado na expectativa que você tinha sobre a segunda.

RTO e RPO devem ser relacionados ao impacto do negócio. Uma clínica que usa o site apenas para apresentar serviços talvez priorize a disponibilidade e os formulários; uma loja ou empresa que recebe dados diariamente precisa discutir restauração de informações e consistência do banco de dados com mais rigor.

O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos apresenta orientações sobre planejamento de contingência para sistemas de informação, incluindo objetivos de recuperação e análise de impacto. A referência ajuda a estruturar perguntas, embora o SLA contratado deva refletir o tamanho e a realidade da sua empresa.

Na prática, peça exemplos de relatórios de monitoramento, método de medição e histórico de incidentes que possam ser compartilhados. Um provedor que informa apenas um percentual, sem explicar a medição, oferece uma garantia difícil de auditar.

Uma cláusula de segurança útil define responsabilidades compartilhadas. O provedor pode cuidar da infraestrutura, da rede e de determinados controles do servidor, enquanto a empresa ou o responsável pelo site precisa manter usuários, senhas, temas, extensões e aplicações atualizados.

No caso do SSL, confirme quem emite, instala, renova e monitora o certificado. Também verifique o que acontece quando a renovação falha e se o suporte ajuda a corrigir conteúdo misto, redirecionamentos ou configurações que impedem o navegador de reconhecer a conexão como segura.

A documentação do MDN sobre HTTPS e segurança na web explica a função do HTTPS na comunicação entre navegador e servidor. Ter SSL ativo é uma base necessária, mas não deve ser apresentado como proteção completa contra invasões ou vazamento de dados.

Backup precisa ser descrito com precisão. Pergunte se a cópia inclui arquivos, banco de dados, configurações, e-mails e certificados, além de saber se os backups ficam separados do ambiente principal e por quanto tempo são mantidos.

Outro ponto decisivo é o teste de restauração. Uma cópia que nunca foi restaurada pode estar incompleta, corrompida ou incompatível com a versão atual do site. Peça um procedimento documentado, responsável técnico, prazo de início e forma de validação após a recuperação.

O plano de recuperação de desastres e backups para sites de pequenas e médias empresas ajuda a organizar essas decisões antes de uma emergência. Ele deve contemplar contatos, prioridades, acessos, dependências externas e critérios para comunicar clientes caso um incidente afete o atendimento.

A política de incidentes também merece atenção. O contrato deve indicar como o provedor comunica indisponibilidade, suspeita de comprometimento, perda de dados e conclusão da investigação, sem expor informações sensíveis desnecessariamente.

Os modelos abaixo não substituem a revisão de um profissional jurídico. Eles servem como linguagem de trabalho para você pedir clareza ao provedor e registrar os pontos que impactam a operação.

Suporte: “Para incidentes classificados como críticos, o provedor deverá confirmar o recebimento em até [prazo], informar a atualização a cada [intervalo] e indicar o responsável pelo escalonamento quando o atendimento não avançar.” Defina também o canal de plantão e o que caracteriza criticidade.

Backups: “O provedor realizará cópias automáticas de arquivos e banco de dados com frequência [diária ou outra], manterá retenção mínima de [período] e informará o procedimento para solicitar restauração.” Acrescente, quando aplicável, a realização periódica de testes de restauração.

SSL: “O provedor deverá manter o certificado SSL válido para os domínios contratados, informar falhas de renovação e atuar na correção de problemas de instalação dentro do escopo técnico definido.” A cláusula precisa separar certificado, aplicação e configuração de DNS.

Incidentes: “Em caso de indisponibilidade relevante ou suspeita de incidente de segurança, o provedor comunicará o cliente pelo canal [canal], com descrição do impacto conhecido, medidas adotadas e atualizações até a normalização.” Evite exigir detalhes que possam aumentar riscos durante uma investigação.

No onboarding da Solução Via Web, um checklist exportável pode conter: domínio e registrador, acessos administrativos, plataforma, versões, banco de dados, e-mails, certificado, rotina de backup, data da última restauração, contatos de emergência, limites contratados, monitoramento, formulário, WhatsApp, Google Analytics, Search Console e campanhas.

Para facilitar a conferência, adicione colunas de responsável, evidência, data de validação e pendência. O campo “backup configurado” não deve ser marcado apenas porque existe um botão no painel; é preciso registrar frequência, retenção e resultado de uma restauração ou validação equivalente.

Empresas que utilizam Joomla ou WordPress também devem incluir atualizações, extensões, permissões de arquivos e rotina de cópia do banco. A checklist de migração para hospedagem gerenciada pode apoiar a organização dos acessos e das dependências quando o contrato envolver mudança de ambiente.