1. Escopo
Este Acordo de Nível de Serviço ("SLA") é incorporado por referência aos Termos de Serviço e rege os compromissos de nível de serviço que assumimos com os clientes que utilizam os Serviços descritos abaixo.
1.1 Serviços cobertos
Este SLA se aplica às seguintes categorias de Serviço:
- Servidores virtuais privados (VPS), incluindo todos os níveis Linux KVM
- Servidores de Protocolo de Área de Trabalho Remota (RDP)
- Servidores dedicados (DS)
- Servidores GPU (GPU)
- Servidores de armazenamento e backup
- Servidores de streaming
- Servidores de jogos
1.2 Serviços com compromissos ajustados
Hospedagem compartilhada e cPanel possuem os compromissos de disponibilidade da Seção 2, mas com medição ajustada para a arquitetura de nível compartilhado (o alvo de medição relevante é a disponibilidade do host compartilhado, em vez da disponibilidade do contêiner por cliente).
1.3 Serviços não cobertos
Hospedagem de e-mail e SMTP possuem compromissos de disponibilidade separados, publicados em suas respectivas páginas de produto. Serviços beta e de pré-visualização explicitamente rotulados como tais não são cobertos por este SLA.
2. Compromisso de Disponibilidade
2.1 Planos padrão
Planos padrão — VPS-1 a VPS-8, RDP-Basic e RDP-Pro, todos os níveis de Storage, Game-S e Game-M, Streaming-1 — possuem um compromisso de disponibilidade mensal de 99,9%.
Uma disponibilidade mensal de 99,9% corresponde a um máximo de 43 minutos e 50 segundos de indisponibilidade em um mês calendário de 30 dias, ou 44 minutos e 38 segundos em um mês de 31 dias.
2.2 Planos Pro, Premium, Dedicados e GPU
Planos de nível superior — VPS-16, RDP-Power, todos os níveis Dedicados (DS-Lite a DS-Beast), todos os níveis GPU (GPU-Lite a GPU-Beast), Game-L, Streaming-2 — possuem um compromisso de disponibilidade mensal de 99,99%.
Uma disponibilidade mensal de 99,99% corresponde a um máximo de 4 minutos e 23 segundos de indisponibilidade em um mês calendário de 30 dias, ou 4 minutos e 28 segundos em um mês de 31 dias.
3. Metodologia de Medição
3.1 Monitoramento externo
A disponibilidade é medida por nós de monitoramento externos operados por provedores terceirizados de uptime (UptimeRobot, Better Uptime ou equivalente). Atualmente mantemos três (3) nós de monitoramento independentes localizados em regiões geograficamente distintas para evitar medição com ponto único de falha.
3.2 Intervalo de sondagem
Cada nó de monitoramento sonda o endpoint primário de cada Serviço a cada cinco (5) minutos.
3.3 Detecção por regra de maioria
A indisponibilidade é registrada quando pelo menos dois dos três nós de monitoramento relatam o Serviço como inacessível na mesma janela de sondagem. Isso evita atribuir interrupções locais de rede no nó de monitoramento a um incidente da MurmurHost.
3.4 Acúmulo de indisponibilidade
Um "minuto de indisponibilidade" é qualquer minuto inteiro durante o qual a detecção por regra de maioria está no estado inacessível. Minutos parciais são arredondados para cima para minutos inteiros para fins de cálculo de crédito.
3.5 Medição pelo lado do cliente
Os clientes podem usar sua própria infraestrutura de monitoramento para corroborar reivindicações de indisponibilidade. Quando a medição pelo lado do cliente divergir materialmente do nosso monitoramento, compartilharemos nossos dados de medição e trabalharemos para chegar a um acordo sobre o período real de indisponibilidade.
4. Créditos de Serviço
4.1 Níveis de crédito
Se um Serviço coberto ficar abaixo do seu compromisso de disponibilidade mensal, o cliente terá direito a um crédito de serviço calculado como uma porcentagem da taxa mensal do Serviço afetado:
| Disponibilidade mensal | Crédito |
|---|---|
| Abaixo de 99,9% (ou 99,99% para níveis superiores), mas ≥ 99,0% | 10% |
| Abaixo de 99,0%, mas ≥ 95,0% | 25% |
| Abaixo de 95,0%, mas ≥ 90,0% | 50% |
| Abaixo de 90,0% | 100% |
4.2 Aplicação
Os créditos de serviço são aplicados à próxima fatura do Serviço afetado. Se o cliente encerrar o Serviço afetado antes da próxima fatura, o crédito será pago como reembolso no método de pagamento original, sujeito aos termos de processamento da Política de Reembolso.
4.3 Limite
O crédito total para qualquer Serviço afetado em qualquer mês individual não pode exceder 100% da taxa mensal desse Serviço. Os créditos de serviço são o único e exclusivo recurso do cliente para qualquer falha no cumprimento dos compromissos de disponibilidade sob este SLA.
5. Exclusões
O seguinte não conta como indisponibilidade para os fins da Seção 2:
5.1 Manutenção planejada
Manutenção anunciada com pelo menos quarenta e oito (48) horas de antecedência através do painel do cliente e da página de status em /status. Janelas de manutenção rotineiras são tipicamente agendadas durante horários de menor movimento para a jurisdição relevante.
5.2 Força maior
Atos de Deus, desastres naturais, guerra, agitação civil, ação governamental, terrorismo ou eventos comparáveis fora do nosso controle razoável.
5.3 Falha do cliente
Indisponibilidade causada por configuração incorreta do cliente, bugs de software controlados pelo cliente, exceder as alocações de recursos do plano ou operações realizadas pelo cliente (como reinicialização voluntária, reinstalação do SO ou mudança de configuração que desabilite o acesso remoto).
5.4 Interrupções de rede de terceiros
Indisponibilidade causada por interrupções de rede de terceiros fora da nossa rede e fora dos nossos acordos de peering, incluindo interrupções do ISP do próprio cliente, provedor de trânsito ou rede de última milha.
5.5 Ação relacionada à AUP
Suspensão sob a AUP não conta como indisponibilidade. Suspensões contestadas pela AUP revertidas em recurso não são retroativamente contadas como indisponibilidade; o recurso do cliente nesse caso está documentado na AUP.
6. Desempenho de Rede
6.1 Metas de latência
Comprometemo-nos com metas de latência mediana entre nossa rede de borda e os principais exchanges regionais de internet, medidas mensalmente:
| Região (origem) | Mediana alvo para o IX mais próximo |
|---|---|
| Islândia (RVK) | < 5 ms para LIX |
| Suíça (ZRH) | < 2 ms para SwissIX |
| Países Baixos (AMS) | < 1 ms para AMS-IX |
| Romênia (BUC) | < 2 ms para InterLAN |
| Moldávia (KIV) | < 5 ms para MD-IX |
| Bulgária (SOF) | < 3 ms para BIX.BG |
| Rússia (MSK) | < 3 ms para MSK-IX |
| Panamá (PTY) | < 4 ms para PA-IX |
6.2 Perda de pacotes
Comprometemo-nos com menos de 0,1% de perda de pacotes no tráfego intra-data center, medido em qualquer janela contínua de 5 minutos, excluindo intervalos afetados por limpeza ativa de DDoS.
6.3 Throughput
Comprometemo-nos com throughput na velocidade da porta configurada no Serviço, menos a sobrecarga típica de encapsulamento e trânsito. Throughput sustentado materialmente abaixo da velocidade da porta (após excluir congestionamento de trânsito fora da nossa rede) é tratado como uma falha de desempenho de rede.
7. Tempo de Mitigação de DDoS
7.1 Ataques volumétricos
Ataques DDoS volumétricos direcionados aos Serviços do cliente são detectados e marcados pela nossa borda de limpeza anycast dentro de sessenta (60) segundos do início do ataque. A mitigação é automática e não requer ação do cliente.
7.2 Ataques na camada de aplicação
Ataques na camada de aplicação (L7) exigem regras específicas da aplicação. Fornecemos regras padrão na borda para padrões comuns; regras adaptadas à aplicação específica do cliente (caminhos de URL, assinaturas de solicitação) são responsabilidade do cliente, opcionalmente configuráveis através do Cloudflare ou BunnyCDN na borda da aplicação.
7.3 Capacidade por nível de plano
A capacidade de limpeza volumétrica escala com o nível do plano e está documentada em /features/ddos-protection. Ataques sustentados acima da capacidade de limpeza do plano podem acionar uma conversa sobre upgrade em vez de um crédito de serviço.
8. SLA de Provisionamento
8.1 Serviços baseados em KVM
Planos KVM VPS, RDP, compartilhados e cPanel concluem o provisionamento dentro de cinco (5) minutos após a confirmação do pagamento. Confirmação é o momento em que o pagamento em criptomoeda atinge as confirmações de limite descritas na página de métodos de pagamento relevante; para pagamentos com cartão onde suportado, a confirmação é a liquidação no processador.
8.2 Dedicados e GPU
Planos dedicados e GPU em estoque concluem o provisionamento dentro de vinte e quatro (24) horas após a confirmação do pagamento. Builds dedicados personalizados (multi-GPU, configurações RAID exóticas, modelos específicos de NIC) são sinalizados no momento do pedido e podem levar de 1 a 3 dias úteis.
8.3 Pedidos em massa
Pedidos em massa (mais de cinco Serviços em uma única transação) exigem coordenação com a equipe de vendas. Os prazos são acordados no momento do pedido e fazem parte do SLA específico do pedido.
8.4 Créditos por falha de provisionamento
Se o provisionamento exceder o alvo relevante em mais de 25%, o cliente terá direito a um crédito de serviço de um mês no Serviço afetado. Isso é adicional a qualquer crédito relacionado à disponibilidade acumulado sob a Seção 4.
9. Tempos de Resposta do Suporte
9.1 Definições de severidade
- Crítica: servidor fora do ar, dados inacessíveis, incidente de segurança em andamento
- Alta: desempenho degradado, interrupção parcial, inacessibilidade intermitente
- Normal: pergunta de configuração, consulta de recurso, esclarecimento de cobrança que não afeta a operação do serviço
- Baixa: feedback de documentação, pergunta de processo, solicitação não sensível ao tempo
9.2 Metas de resposta
| Severidade | Primeira resposta | Atualização horária | Meta de resolução |
|---|---|---|---|
| Crítica | 30 minutos | a cada hora | melhor esforço, página de status atualizada |
| Alta | 2 horas | a cada 4 horas | melhor esforço dentro de 1 dia útil |
| Normal | 24 horas | conforme necessário | dentro de 3 dias úteis |
| Baixa | 48 horas | conforme necessário | dentro de 5 dias úteis |
9.3 Canais de suporte
Tickets são aceitos através do painel do cliente e por e-mail para [email protected]. O chat 24/7 (onde disponível, carregado lentamente conforme a documentação em /features) é para consultas gerais; problemas de severidade Crítica devem sempre também ser abertos como tickets para garantir o rastreamento.
10. Como Reivindicar Créditos
10.1 Janela de reivindicação
Os créditos de serviço devem ser reivindicados dentro de trinta (30) dias do incidente que dá origem ao crédito. Créditos não reivindicados dentro desta janela são perdidos.
10.2 Procedimento de reivindicação
Para reivindicar um crédito, envie um e-mail para [email protected] com as seguintes informações:
- E-mail da conta e identificador do Serviço afetado
- Data e hora do incidente em UTC
- Motivo da reivindicação (falha de disponibilidade, falha de provisionamento, falha de desempenho de rede)
- Quaisquer dados de monitoramento externo que o cliente tenha corroborando o incidente
10.3 Processamento
Reconhecemos as reivindicações dentro de quarenta e oito (48) horas. A resolução substantiva normalmente é concluída dentro de sete (7) dias úteis. Créditos aprovados são aplicados à próxima fatura ou, a pedido do cliente, pagos como reembolso conforme a Seção 4.2.
11. Janelas de Manutenção
Avisos de manutenção são publicados na página de status em /status e enviados por e-mail a todos os clientes afetados. A janela padrão de aviso é de quarenta e oito (48) horas. Manutenção de emergência — necessária para resolver um problema ativo de segurança ou estabilidade — pode ser realizada sem aviso prévio; nesse caso, um post-mortem é publicado na página de status dentro de cinco (5) dias úteis.
12. Modificações a Este SLA
Podemos atualizar este SLA periodicamente. Mudanças materiais que reduzam o nível de serviço garantido sob este SLA exigem aviso prévio de trinta (30) dias através do procedimento na Seção 15 dos Termos de Serviço. Mudanças que melhorem os compromissos ou esclareçam a linguagem entram em vigor imediatamente na publicação. A data de "Última atualização" no topo deste documento reflete a mudança mais recente.