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 na síntese pública em audit-rebuttal-2026)

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	comunidade (GitHub Discussions)	—	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	10 % da fatura mensal
Business	99,9 %	30 min	2 h	8 h úteis (e-mail prioritário)	12×5 (07–19 BRT)	25 % da fatura mensal
Enterprise	99,9 % operacional / ≥99,95 % contratual	30 min	1 h	4 h úteis (Slack Connect + e-mail)	24×5 com on-call escalado	50 % da fatura mensal
Ultra	99,95 %	15 min	15 min	1 h úteis (Slack dedicado + pager)	24×7 com on-call primário e secundário	100 % da fatura mensal
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 7 dias de antecedência 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 alvo de RPO ≤ 1 h (Enterprise) será entregue pelo serviço de backup horário (pg_dump → S3, cron nativo no Railway) quando habilitado; até lá vale o backup noturno (RPO de até 24 h). RPOs abaixo de 1 h (Ultra) dependem de arquivamento contínuo de WAL, no roadmap.
• Suporte (1ª resposta): tempo entre abertura do ticket e o primeiro contato humano (não automatizado).
• Crédito por SLA quebrado: crédito proporcional aplicado à próxima fatura, mediante solicitação formal em até 30 dias do incidente.

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

Tickets Sev 1 / Sev 2 no Ultra disparam o pager rotativo do time de plantão; Sev 3 / Sev 4 são roteados via Slack Connect (Enterprise) ou Slack dedicado (Ultra).

Escalonamento

L1 — primeira resposta (suporte)
  ↓ se não resolvido no SLA da severidade
L2 — engenharia de plantão (on-call)
  ↓ se não resolvido em 2× o SLA da severidade
L3 — engenharia sênior / autor do módulo afetado
  ↓ se Sev 1 não resolvida em 4 h
Diretoria técnica (Daniel Novais)

Em Sev 1, o gerente de contas (Enterprise/Ultra) é notificado ao mesmo tempo que o L2.

Janelas de manutenção planejada

• Janela padrão: domingos 04:00–06:00 UTC, com pré-anúncio de no mínimo 72 h por e-mail e em Status de produção.
• 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-mail de incidente e página de status.
• 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)
• GET /metrics — Prometheus (uptime, p50/p95/p99 por rota, erros 5xx)
• Página de status pública: Status de produção
• 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, SageMaker custom-models, 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). Veja TTP Board Adoption Brief.
• 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).