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/readydeve responder200 OKem ≤ 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). |