Este documento integra os Termos de Serviço por referência e estabelece as definições, o método de medição e o processo de reivindicação relativos à disponibilidade da Plataforma. É um modelo base e não constitui aconselhamento jurídico — revise antes do primeiro deploy em produção.
A medição de disponibilidade descrita na Seção 2 está em produção e
publicada em /status. As faixas percentuais de garantia e o crédito de
serviço da Seção 6, abaixo, são no entanto valores provisórios: ainda não
foram confirmados pelo responsável por este fork, carregam o marcador
TODO: na configuração jurídica (src/config/legal.ts) e aparecem no
cartão de prontidão jurídica do /admin até serem substituídos por decisão
própria de negócio e jurídica. Não trate os números da Seção 6 como
compromisso final até essa substituição.
1. Definição de disponibilidade
Para os fins deste documento, a Plataforma é considerada disponível em um
dado instante quando o endpoint público GET /api/health responde com status
200. Indisponibilidade é o tempo em que essa checagem não responde 200
(por erro, timeout ou ausência de resposta), excluído o tempo coberto por
janela de manutenção anunciada nos termos da Seção 3 e pelas exclusões da
Seção 4.
2. Método de medição
O método de referência de disponibilidade é a agregação diária do sinal de
saúde do serviço (a mesma checagem lógica do endpoint público GET /api/health — uma consulta trivial ao banco de dados), consolidada na
tabela interna uptime_daily e mantida em produção pelo Fornecedor. O
rollup diário é retido indefinidamente; as amostras brutas que o alimentam
(uptime_sample) são retidas por 90 dias. O percentual de disponibilidade
do mês corrente e dos três meses anteriores, junto com a latência p95 mais
recente, é publicado em /status.
Cada amostra é colhida internamente pelo processo de cron de manutenção da
Plataforma, não por uma requisição HTTP separada ao endpoint público. Na
prática, isso significa que um período em que o processo da aplicação como
um todo ficou totalmente inacessível pode não gerar amostra alguma para essa
janela — o intervalo aparece como "sem dado" em /status, e não como
indisponibilidade contabilizada. É exatamente para esse cenário que existe o
processo de reivindicação manual descrito nesta seção e detalhado na Seção 5.
Um incidente registrado manualmente em /status conta como indisponibilidade
para fins de reivindicação mesmo quando as amostras automatizadas do período
correspondente não capturam falha — por exemplo, uma degradação que não
derruba o endpoint de saúde, mas afeta funcionalidade real da Plataforma. Por
isso, a decisão sobre crédito de serviço (Seção 6) é sempre uma revisão
humana que considera os dois sinais em conjunto — o número apurado por
uptime_daily e o registro de incidentes — nunca um cálculo automático feito
só a partir de uptime_daily.
3. Janelas de manutenção
Manutenção programada que possa afetar a disponibilidade é anunciada com
antecedência na página pública de status da Plataforma (/status). Tempo
coberto por uma janela de manutenção corretamente anunciada não conta como
indisponibilidade para os fins deste documento.
4. Exclusões
Não são consideradas indisponibilidade, para nenhum efeito deste documento:
- manutenção anunciada nos termos da Seção 3;
- evento de força maior, fora do controle razoável do Fornecedor;
- uso da Plataforma fora do aceitável, conforme o documento de Uso Aceitável;
- falha ou omissão do próprio Cliente, incluindo as hipóteses descritas nos Termos de Serviço como responsabilidade do Cliente pela segurança e uso da própria conta;
- indisponibilidade de serviço de terceiro contratado diretamente pelo próprio Cliente, incluindo, sem limitação, provedor de inteligência artificial usado via Chave BYOK.
5. Processo de reivindicação
O Cliente que entender ter havido indisponibilidade fora das exclusões da Seção 4 pode registrar reivindicação em até 30 dias corridos após o incidente, pelo canal de suporte. O Cliente pode contestar o cálculo de disponibilidade apresentado pelo Fornecedor com evidência própria (por exemplo, registro próprio de monitoramento externo); o ônus de reconciliar a divergência entre os dados do Fornecedor e a evidência do Cliente é do Fornecedor, não do Cliente.
6. Garantia de disponibilidade e crédito de serviço
Para organização em plano pago ativo — a Seção 7 trata das exceções de plano gratuito, trial e recurso beta — o Fornecedor garante disponibilidade mensal de TODO: 99.9%, apurada pelo método da Seção 2.
Quando a disponibilidade apurada no mês ficar abaixo de TODO: 99.9%, o Cliente tem direito a crédito de serviço equivalente a TODO: 10% do valor da fatura daquele mês. Quando a disponibilidade apurada no mês ficar abaixo de TODO: 99.0%, o crédito passa a TODO: 25% do valor da fatura daquele mês. As faixas não se acumulam: aplica-se sempre a faixa mais severa em que o mês se enquadrar.
O crédito de serviço é limitado a 100% do valor da fatura do mês afetado e é aplicado conforme o processo de reivindicação da Seção 5. Ele é o remédio exclusivo do Cliente por indisponibilidade dentro do escopo deste documento, afastando outro pedido de indenização pelo mesmo fato, sem prejuízo do disposto na Seção 11 dos Termos de Serviço.
7. Planos gratuitos, trial e recursos beta
Organização em Plano gratuito ou em período de trial não tem garantia de disponibilidade sob este documento. Funcionalidade em beta não é coberta por SLA em nenhuma hipótese — ver Termos de Trial e Beta.
8. Contato
Dúvidas sobre este documento ou sobre uma reivindicação de disponibilidade: TODO: suporte@exemplo.com.br.