SLA, uptime e disponibilidade: o que realmente importa numa PaaS

“99,99% de uptime garantido.” Você vê o número na home da PaaS, marca na cabeça como “muito confiável”, e segue. Quem é que vai ler a letra miúda?

Aí seu app cai. Você abre a página de status do provider. Está tudo “operational” — verde. Mas o seu app está fora. Você abre ticket. Suporte responde: “Não há incidente atual. Verifique sua configuração.” Você passa 3 horas debugando algo que era do provider.

No mês seguinte chega o crédito proporcional ao downtime registrado: US$ 7,43. Você perdeu R$ 8.000 em vendas naquele dia. O credit não cobre nem o café da semana.

Esse post é sobre o que SLA realmente garante (e o que não garante). Sobre por que 99,9% e 99,99% — apesar de parecerem similares — significam realidades operacionais muito diferentes. E sobre o que olhar quando você escolhe PaaS pra rodar app de produção sério.

O que é SLA na prática (e o que não é)

Vamos resetar o vocabulário, porque essa área é cheia de confusão.

SLA (Service Level Agreement) é um contrato que estabelece nível de serviço esperado e remediação em caso de falha. Tem três componentes:

1. Métrica garantida (ex: 99,9% de uptime no período de medição)
2. Como a métrica é medida (downtime conta como? Manutenção planejada conta? Parcial conta?)
3. Remediação em caso de violação (credit em serviço, geralmente)

Uptime é a métrica em si — quanto tempo o serviço está disponível.

Status page é a comunicação pública de incidentes. Não é o SLA — é a fonte de informação.

A confusão típica: “Vercel tem 99,99% de uptime no status page” ≠ “Vercel tem SLA contratual de 99,99%”. O status page reporta o que aconteceu (uptime medido). O SLA contratual é o que eles se comprometem a manter — e geralmente o número contratual é mais baixo que o que aparece no status page.

Importante: SLA contratual geralmente só existe em planos pagos enterprise. Pra planos starter/pro, é “best effort” — sem promessa contratual de número específico.

A matemática dos noves

Cada nove adicional na promessa de uptime parece pequeno, mas o downtime permitido despenca exponencialmente:

Uptime	Downtime/ano	Downtime/mês	Downtime/semana	Equivalente humano
99% (dois noves)	3 dias, 15h	7h 18min	1h 41min	”Cai um dia útil por mês”
99,9% (três noves)	8h 45min	43min	10min	”Cai uma manhã por mês”
99,95%	4h 22min	21min	5min	”Quase nunca cai”
99,99% (quatro noves)	52min	4min 22s	1min 1s	”Esquecem que pode cair”
99,999% (cinco noves)	5min 15s	26s	6s	”Operação militar”

Tomemos um exemplo concreto: você é SaaS B2B com 200 clientes. Cada hora de downtime custa R$ 5.000 em SLA failures (contratos com seus clientes) + R$ 2.000 em produtividade interna + R$ X em perda de novos signups. Vamos dizer R$ 8.000/hora.

Com SLA 99% (8h45 downtime/mês): você sangra ~R$ 70.000/mês em downtime. Com SLA 99,9%: ~R$ 5.700/mês. Com SLA 99,99%: ~R$ 580/mês.

A diferença entre três noves e quatro noves vale R$ 60.000/ano pro seu caso típico. Faz sentido pagar Enterprise pra quatro noves se você está nessa ordem de grandeza.

O que está no SLA da AWS, Vercel, Railway, Heroku

Vamos abrir a letra miúda de quatro players relevantes em 2026:

AWS Compute SLA

• EC2 Multi-AZ: 99,99% por região (4 noves)
• EC2 Single AZ: 99,5% (entre 2,5 e 3 noves)
• RDS Multi-AZ: 99,99%
• Lambda: 99,95%

Como medido: “Monthly Uptime Percentage” calculado por AWS por mês, por região, por serviço. Exclusões:

• Manutenção planejada (anunciada com 7 dias)
• Falhas causadas pelo cliente
• Atos de força maior (definição ampla)

Remediação: credit em serviço, escalonado:

• 99% a 99,99%: 10% de credit
• 95% a 99%: 30%
• < 95%: 100%

Credit é em USD aplicado em fatura futura. Não cobre prejuízo do seu app.

Vercel SLA

• Free/Hobby: sem SLA contratual
• Pro: sem SLA contratual (“best effort”)
• Enterprise: 99,99% (4 noves) declarado em contrato custom

Como medido: por uptime de “Vercel platform”. Edge network, builds e deploys são tratados separadamente.

Remediação: credit em serviço pra Enterprise. Termos negociados case-by-case.

Railway SLA

• Hobby/Pro: “best effort”, sem número contratual
• Pro Plan ($20/mo): sem SLA contratual explícito

Como medido: Railway tem status page público mas sem garantia contratual de SLA pra planos < Enterprise.

Heroku SLA

• Eco/Basic: sem SLA
• Standard/Performance: “Heroku will use commercially reasonable efforts” — sem porcentagem específica
• Heroku Shield/Private Space (Enterprise): SLA contratual negociado

O padrão da indústria

Você percebe o padrão: só Enterprise tem SLA contratual com porcentagem específica. Planos starter/pro são “best effort”. Você está pagando por funcionalidade, não por garantia de uptime.

Pra startup pequena, isso costuma estar ok — você nunca vai conseguir credit significativo mesmo. Pra empresa que opera SaaS B2B com SLAs com clientes, é problema sério: você se compromete a 99,9% com seu cliente mas o seu provider não te dá nada por escrito.

Como SLA vira credit: o jogo da indenização

Aqui mora a parte mais cruel. Imagine: AWS teve outage de 6h no us-east-1 em 2021 (caso real). Empresas perderam milhões em receita.

A AWS aplicou credit conforme SLA. Cálculo típico:

• Sua fatura mensal: US$ 1.000
• Downtime: 6h = ~0,83% do mês
• SLA AWS de 99,99% foi violado: credit de 30% sobre a fatura
• Credit: US$ 300

Se você perdeu US$ 200.000 em vendas durante essas 6h: você recebe US$ 300.

Esse é o modelo de “credit em serviço”. Não é “indenização” em sentido legal — é desconto em fatura futura. Não é dinheiro de volta no seu caixa. Não é cobertura de prejuízo do seu negócio.

Pra quem opera B2B com SLAs com clientes pagos, isso é insuficiente. Você se compromete em milhões e o provider te indeniza em centenas. A solução são:

1. Seguro de indenização — pouca gente faz, mas existe (cyber insurance cobre outage de provider em alguns produtos)
2. Cláusulas customizadas em contrato Enterprise — onde você negocia indenização real, não credit
3. Arquitetura redundante multi-provider — pra reduzir dependência em uma única falha

A maioria das startups acaba absorvendo o prejuízo de outage e seguindo. É o custo de fazer negócio com PaaS — a menos que o porte justifique multi-cloud (e o porte raramente justifica antes de tens-of-millions ARR).

O que faz uptime real ser alto

A pergunta importante não é “qual SLA o provider promete?” — é o que faz o uptime real ser alto?.

Quatro pilares técnicos:

1. Redundância em todas as camadas

• Energia: feed A + feed B + nobreaks + geradores
• Network: dois provedores de trânsito IP, peering em múltiplos PTTs
• Compute: cluster com N+1 ou N+2 nós (perda de um não derruba serviço)
• Database: replicas síncronas + assíncronas, failover automático
• Storage: replicação multi-disco, snapshots automáticos

A perda de qualquer componente único não pode derrubar o serviço.

2. Failover automático testado

Redundância só vale se o failover funcionar. Provider sério testa failover regularmente (chaos engineering). Faz parte do plano de DR (Disaster Recovery).

3. Deploy strategies que não derrubam produção

• Blue-green deployment com auto-revert (deploy novo coexiste com antigo até saúde validar)
• Canary deploys (rollout gradual, observado)
• Rollback < 30 segundos em caso de problema

Maior fonte de outage histórica em PaaS = deploys ruins. Estratégia certa elimina essa categoria.

4. Monitoring 24/7 + on-call response

Detecção rápida + response rápido reduz MTTR (Mean Time To Recover). Provider com observabilidade contínua e plantão treinado tem incidentes mais curtos.

Esses pilares são técnicos — não promessa de contrato. Provider que tem os quatro entrega uptime alto independente do número que escreve no marketing.

O caso Upuai: arquitetura de disponibilidade

A Upuai opera com os quatro pilares:

• Redundância A+B no datacenter de BH: energia duplo feed, geradores, nobreaks; dois trânsitos IP independentes; cluster Kubernetes com tolerância a falhas de nó.
• Deploys blue-green com auto-revert: todo deploy roda paralelo ao deploy anterior; se o novo falha health check, volta automaticamente pro anterior. O serviço antigo continua atendendo até o novo provar saúde.
• Backups contínuos PITR (Point-in-Time Recovery) pra databases: Postgres CNPG faz backup contínuo com restore granular a qualquer ponto da janela.
• Monitoring 24/7 com plantão técnico interno: equipe BR de plantão pra incidentes production-down.

SLA contratual por tier:

Tier	Disponibilidade alvo	SLA contratual
Free	Best effort	—
Starter	Best effort	—
Pro	99,9% target	—
Business	99,9% target	Credit policy padrão
Enterprise	99,99% target	SLA contratual + créditos negociáveis

Status page público com histórico de incidentes (incluindo postmortems detalhados quando algo dá errado — princípio de transparência sobre o que aconteceu e o que mudou pra não acontecer de novo).

Como você como cliente pode mitigar

Mesmo com provider sólido, você não delega 100% da responsabilidade pelo uptime do seu app. Mitigações de sua parte:

Healthcheck próprio em endpoint conhecido

Implemente /health que reflete saúde real do seu app (DB conectado, cache respondendo, dependências ok). Não só “200 OK estático”.

Monitoring externo independente

Use ferramenta de monitoring fora do provider (Pingdom, UptimeRobot, BetterStack). Se sua app cai junto com seu monitoring do mesmo provider, você nunca vê.

Backup que você controla

Mesmo que o provider faça backup, mantenha cópia em formato portável em provider diferente (ou local). Bucket S3 em conta diferente, backup semanal automatizado.

Postmortem culture interna

Quando você tem incidente (seu ou do provider), faça postmortem honesto. Identifique o que falhou em cada camada (provider, seu código, seu monitoring, seu response). Sem culpa, com aprendizado.

Multi-region quando faz sentido

Pra workloads críticos com porte grande, considere multi-region — mesmo dentro do mesmo provider, ou cross-provider. Custo cresce; risco cai. Análise caso a caso.

Comparativo lado a lado

Perguntas frequentes

99,9% é suficiente pro meu app? Depende do quanto downtime custa pra você. Se seu app gera R$ 1.000 de receita por hora e cai 8h por mês, são R$ 8.000/mês de perda — provavelmente vale subir pra plano com 99,99%. Se é R$ 100/hora (app interno, ferramenta), 99,9% basta.

SLA “best effort” tem valor algum? Tem o valor do histórico do provider. Provider que entrega 99,99% historicamente (mesmo sem contrato escrito) é melhor que provider com 99,99% no contrato mas histórico de outages frequentes. Olhe o status page público dos últimos 12 meses — esse é o número real.

Posso confiar no status page do provider? Em geral sim — providers sérios reportam outages com transparência (boom de mídia ruim quando escondem). Mas combine com monitoring externo independente pra verificar.

Como medir o uptime do meu app? Healthcheck de fora (do ponto de vista do usuário). UptimeRobot grátis pra monitoramento básico; BetterStack ou Pingdom pra setup mais completo. Mede HTTP 200 + tempo de resposta a cada 1-5min, de múltiplas localizações.

O que faz mais diferença na prática — promessa contratual ou arquitetura redundante? Arquitetura. Promessa contratual te dá credit; arquitetura redundante te dá uptime real (e poupa dinheiro do prejuízo de outage). Olhe o que o provider tem em redundância A+B, deploy strategy, monitoring — esses são os números que importam.

Faz sentido multi-cloud pra hedge de SLA? Pra empresa com receita > 10M ARR onde minutos de downtime custam dezenas de milhares, sim. Pra startup early-stage, overhead operacional de multi-cloud quase sempre supera o benefício. Single-provider sólido com backup independente é o sweet spot.

---

SLA é parte da equação de operar produção. Suporte rápido é a outra metade — leia Suporte em português e SLA brasileiro e Bare metal próprio vs cloud terceirizada pra o quadro completo.