SLA por tier — alvos públicos

Esta página resume os compromissos de nível de serviço (SLA) que o TELECOM-TOWER-POWER pratica por plano de assinatura. Os valores aqui publicados são alvos operacionais do produto SaaS multi-tenant hospedado no Railway; o SLA contratual de cada cliente é o que está assinado em sua MSA ou Order Form e prevalece sobre esta tabela em caso de conflito.

Esta página foi criada em resposta à auditoria 2026-05 (claims #61,

62 e #63 da auditoria 2026-05; histórico sob pedido em security@telecomtowerpower.com.br)

para tornar visíveis os compromissos de disponibilidade e suporte sem exigir consulta comercial.

Tabela resumo

Tier	Uptime alvo (mensal)	RTO	RPO	Suporte (1ª resposta)	Janela suporte	Crédito por SLA quebrado
Free	best-effort	best-effort	best-effort	e-mail, sem prazo (best-effort)	—	nenhum
Starter	99,5 %	2 h	12 h	3 dias úteis (e-mail)	8×5 horário comercial BRT	nenhum
Pro	99,5 %	1 h	4 h	1 dia útil (e-mail)	8×5 horário comercial BRT	nenhum (Termos §6.1)
Business	99,9 %	30 min	2 h	8 h úteis (e-mail prioritário)	12×5 (07–19 BRT)	nenhum (Termos §6.1)
Enterprise	99,9 % operacional / ≥99,95 % contratual	30 min	1 h	4 h úteis (Slack Connect + e-mail)	24×5	10 a 50 % da fatura (política de reembolso)
Ultra	99,95 %	15 min	15 min	2 h (canal dedicado, no contrato)	24×7, no contrato	definido no contrato
Perpetual / on-prem	definido pelo cliente	definido pelo cliente	definido pelo cliente	suporte L3 sob contrato	conforme contrato	conforme contrato

Definições:

• Uptime alvo (mensal): percentual do período de faturamento em que o endpoint público /health/ready deve responder 200 OK em ≤ 2 s da borda do Railway. Janelas de manutenção comunicadas com pelo menos 24 h de antecedência (Termos §6.2) não contam contra o alvo.
• RTO (Recovery Time Objective): tempo máximo para restaurar o serviço após um incidente confirmado em Sev 1 / Sev 2.
• RPO (Recovery Point Objective): janela máxima de perda de dados aceitável (em uma restauração de backup). O RPO ≤ 1 h (Enterprise) vem do backup horário (pg_dump → MinIO na Railway, cron nativo do Railway); os RPOs abaixo de 1 h (Ultra) vêm do arquivamento contínuo de WAL (PITR). As três cadeias — noturna, horária e PITR — passaram no ensaio de restauração de 05/10/2026 (GET /status/reliability → last_restore_drill).
• Suporte (1ª resposta): tempo entre abertura do ticket e o primeiro contato humano (não automatizado). No Enterprise e no Ultra, o resumo dá o prazo da Sev 3; os das outras severidades estão na tabela abaixo.
• Crédito por SLA quebrado: só o Enterprise tem crédito em tabela pública, pelas faixas da política de reembolso (10 % abaixo de 99,95 %, 25 % abaixo de 99,0 %, 50 % abaixo de 95,0 %). O Ultra e o perpétuo/on-prem seguem o contrato. Do Free ao Business vale o esforço razoável de disponibilidade dos Termos §6.1, sem crédito.

Severidade e tempos de resposta

Severidade	Definição	1ª resposta (Enterprise)	1ª resposta (Ultra)
Sev 1	API/CLI indisponível para todos os usuários do tenant; perda de dados em andamento	30 min	15 min
Sev 2	Degradação severa: latência p95 > 5 s, fila de jobs parada, erros 5xx > 1 %	1 h	30 min
Sev 3	Funcionalidade não-crítica indisponível; workaround existe	4 h	2 h
Sev 4	Pergunta, melhoria, documentação	1 dia útil	4 h

Hoje quem atende é o fundador: um Sev 1 ou Sev 2 chega a ele pelos alertas automáticos de produção, e o primeiro contato humano segue os prazos acima. O pager e o canal dedicado do Ultra são montados no contrato; Sev 3 / Sev 4 seguem pelo Slack Connect (Enterprise) ou pelo canal do contrato (Ultra).

Escalonamento

A equipe é pequena: o suporte (1ª resposta), a engenharia de plantão e a diretoria técnica são hoje a mesma pessoa, o fundador (Daniel Azevedo Novais). Por isso não há níveis L1/L2/L3 nem gerente de contas: o incidente vai direto a quem o resolve. Quando a equipe crescer, a escada de escalonamento volta a esta página.

Janelas de manutenção planejada

• Janela padrão: domingos 04:00–06:00 UTC, com pré-anúncio de no mínimo 24 h por e-mail (Termos §6.2).
• Janelas de emergência (CVE crítica, mitigação de incidente em andamento) podem ser executadas a qualquer momento com pré-anúncio de até 4 h via Slack Connect (Enterprise/Ultra) e e-mail de incidente.
• Manutenções planejadas não contam contra o uptime alvo.

Como acompanhar disponibilidade em tempo real

• Healthcheck público (sem autenticação):
• GET /health — liveness (resposta constante, sem I/O)
• GET /health/ready — readiness (DB, SRTM, fila, flag offline)
• Disponibilidade e latência medidas, sem chave de API: GET /status/reliability (uptime das sondas, p50/p95 do tráfego servido, taxa de erro, ensaios de restauração)
• Página de status pública: status.telecomtowerpower.com.br
• GET /metrics (Prometheus) exige autenticação (bearer) desde 12/10/2026: só o Prometheus de produção o raspa.
• Auditor independente: clientes Enterprise / Ultra recebem acesso ao dashboard interno do Grafana mediante NDA.

Suporte e escopo

Itens fora do escopo de qualquer SLA acima:

• Integrações de terceiros (Ollama, MapBiomas Overpass) — suportadas em base best-effort.
• Outorgas e homologações ANATEL — o TTP é ferramenta de triagem/due-diligence; não substitui o processo formal junto à ANATEL nem a assinatura de profissional habilitado (eng. de telecomunicações com CREA).
• Modificações personalizadas no código fechado para clientes Pro ou inferior — disponíveis apenas a partir do Business, sob contrato separado de SOW.

Histórico

Versão	Data	Notas
1.0	2026-05-29	Publicação inicial — fecha lacuna apontada pela auditoria 2026-05 (claims #61, #62, #63 na síntese pública).
1.1	2026-10-14	O resumo do Ultra passa a dar o prazo da Sev 3 (2 h), como o do Enterprise; antes dizia «1 h úteis», um número que a tabela de severidade não tinha, e «úteis» numa janela 24×7. O /metrics sai da lista de healthchecks públicos: exige bearer desde 12/10/2026.