Monitoramento de uptime para SaaS — você sabe antes do primeiro chamado.
A Uptimia atribui à sua API pública, ao fluxo de entrar e à tarefa de faturamento da noite anterior uma verificação própria a cada uma, em vez de adivinhar pela página inicial que continua carregando. Uma falha é confirmada a partir de mais de uma região antes de notificar quem estiver de plantão — no Slack, PagerDuty ou onde a sua equipe costuma olhar.
Step breakdown
All 2 steps passedFailed at step 2244 ms · 02:13236 ms · 02:147-day averagesLast runAssertions — step 2
3 of 3 passing0 of 3 passedResponse — step 2
200 · 96 ms502 · 84 msRecent Runs
every minute · rotating locations
New York✗ Failed at step 20.24 s
Frankfurt✗ Failed at step 20.24 s
London✓ All 2 steps passed0.25 s
Sydney✓ All 2 steps passed0.26 s
Amsterdam✓ All 2 steps passed0.23 sNew York✓ All 2 steps passed0.24 s
Tokyo✓ All 2 steps passed0.25 sQuatro crenças que fazem perder clientes de SaaS
Cada uma parece razoável — e cada uma deixa uma falha decorrendo até um cliente a encontrar.
"Se algo tivesse avariado, os clientes diziam-nos."
Os que avisam são os fiéis. Um potencial cliente que encontra um cadastro avariado fecha o separador e nunca se torna cliente — não há ninguém para se queixar, nem nada na sua caixa de entrada para investigar.
"Estamos na AWS — a disponibilidade é problema deles."
O SLA deles cobre a infraestrutura deles, não o seu produto. Um deploy mal feito, um certificado expirado, um worker de fila encravado — esses problemas são sempre seus, e a página de estado do fornecedor continua verde em todos esses casos.
"A aplicação carrega, logo estamos operacionais."
Um SaaS é um conjunto de funcionalidades, não uma única página. O dashboard pode carregar enquanto a API pública deixa de responder, o entrar falha ou a tarefa de faturamento salta silenciosamente uma noite — cada uma falha por si, e "operacional" esconde tudo isso.
"Admitir incidentes publicamente dá má imagem."
O silêncio dá pior imagem. Um cliente que encontra uma nota de estado não abre chamado de suporte nenhum — e lembra-se de que o avisaram antes de perguntar. Um cliente que não encontra nada assume que também não sabem.
"Três noves é praticamente perfeito" é a maior delas. 99,9% de disponibilidade permite 43 minutos de indisponibilidade por mês. Num site institucional isso é um erro de arredondamento — mas os clientes trabalham dentro de um SaaS. Multiplique 43 minutos por 500 clientes: 21.500 minutos-cliente, 358 horas por mês em que alguém encontra o seu produto avariado.
As renovações não são decididas pela sua percentagem de disponibilidade. São decididas por quem descobriu primeiro, e por quão depressa foi corrigido.
Eis o aspeto dessa falha quando uma cadeia está vigiando o endpoint.↓ minuto a minuto
Uma interrupção de API, do início ao fim
O endpoint da conta deixou de funcionar. O dashboard continuou carregando, o ping da página inicial manteve-se verde, e todas as integrações que chamavam esse endpoint já estavam falhando.
Isto cobre a API. Mas um SaaS falha em quatro camadas — aplicação, API, fluxos, tarefas — e cada uma falha por si.↓ cada camada
Cada camada do seu produto, vigiada
As verificações testam a sua API e as suas páginas, um browser real reproduz o entrar e o cadastro, as suas tarefas enviam pings, e um snippet reporta o que os usuários reais obtiveram — tudo reunido num único dashboard, numa única lista de contatos.
Feito para as falhas de SaaS
A API que os seus clientes chamam
Uma página inicial que carrega não diz nada sobre o endpoint que as integrações deles chamam — por isso é um cliente que hoje o avisa. A Uptimia executa antes uma cadeia de pedidos reais à sua API pública, com uma frequência até uma vez por minuto: entrar, obter o token, chamar o endpoint protegido, ler a resposta.
- Cadeias até 15 passos — cada passo verifica a resposta que recebeu e passa ao seguinte o que este precisa
- Entra primeiro — entra e só depois chama os endpoints a que apenas um cliente autenticado tem acesso
- Confirmado, não instável — um passo com falha é verificado a partir de até três localizações antes de abrir um incidente
Entrar e cadastro, testados antes dos clientes
Depois de um deploy, a primeira pessoa a tentar entrar devia ser um robô. A Uptimia reproduz o entrar e o cadastro num browser real a partir de 13 localizações, com uma frequência de até 10 em 10 minutos, e abre um incidente no momento em que um passo falha — com uma captura de tela da página no momento da falha.
- Um browser real — acede à página, preenche os campos, clica, verifica o resultado
- Captura de tela na falha — o waterfall mostra o passo que falhou e o aspeto da página
- Tempos por passo — durações por passo, para que um fluxo mais lento apareça antes de falhar
A tarefa de faturamento que nunca correu
Um cron que morre não avisa — nada parece "indisponível" a partir de fora enquanto as faturas silenciosamente não são emitidas. Os heartbeats mudam isso: a sua tarefa envia um ping à Uptimia quando termina, e um ping em falta é o incidente.
- Um único URL de ping — uma linha no fim de um cron, worker ou script de cópia de segurança
- Defina quando é esperado — um horário e um período de tolerância; um ping que nunca chega abre o incidente
- Sinais de início & falha também — apanha uma tarefa que começou mas nunca terminou, ou que reportou a sua própria falha
Página de estado no seu domínio
Antes de abrir um chamado de suporte, um cliente procura uma página que diga que já sabe. Coloque uma no seu próprio domínio — o seu logotipo, o emblema da Uptimia desativado — mostrando o estado em tempo real, 90 dias de histórico e todas as notas de incidentes, com os assinantes recebendo um e-mail em cada atualização.
- O seu domínio, SSL automático —
status.suaapp.compor HTTPS, o emblema "Powered by Uptimia" removível - Secções & assinantes — agrupe monitores por área, publique atualizações de incidentes e manutenção, notifique assinantes
- Pública ou privada — aberta aos seus clientes, ou protegida por senha
Um incidente, a sua equipe e a sua página de estado
O mesmo incidente confirmado notifica quem estiver de plantão e atualiza a página que os clientes já andam a atualizar.
Microsoft Teams12 canais de alerta, uma única lista de contatos — e a página de estado que os seus clientes acompanham, atualizada a partir do mesmo incidente.
Ver o diretório completo de integrações →Uma interrupção devia notificá-lo.Não seus clientes.
O teste de 30 dias abre todos os tipos de monitor — cadeias de API, fluxos de início de sessão, heartbeats e verificações de disponibilidade.
Configure o monitoramento de SaaS em três passos
Os caminhos críticos do seu produto podem ficar monitorados ainda esta tarde.
Aponte verificações ao seu produto
Adicione uma verificação de disponibilidade na aplicação, uma cadeia de pedidos contra a sua API pública, e uma reprodução de início de sessão num browser real.
Ligue heartbeats às suas tarefas
Coloque o URL de ping no fim de cada cron, worker ou cópia de segurança — um ping em falta torna-se um incidente.
curl -fsS uptimia.com/p/hb_9f3c…
Direcione alertas & publique o estado
Envie alertas para o Slack e o PagerDuty, escolha quem é notificado a seguir se ninguém confirmar, e coloque a disponibilidade e os fluxos numa página de estado.
Também incluído
Veja o que os usuários reais sentem
Um snippet JavaScript passivo reporta os tempos de carregamento dos usuários reais, por dispositivo, browser e localização.
Automatize a partir da API
Crie monitores e páginas de estado a partir das suas próprias ferramentas — configure verificações num script de deploy.
Janelas de manutenção
Lançando uma versão? Agende a janela — as verificações pausam, os alertas ficam em silêncio, a página de estado mostra o trabalho planejado.
Um incidente, um alerta
Uma tempestade de alertas torna-se um único resumo, não uma centena de pings — com um link assinado para confirmar e o MTTA registrado.
Avisos de recuperação
Quando a API volta a funcionar, os engenheiros que foram notificados também recebem o sinal de recuperação.
Ferramentas gratuitas para depurar depois
Trace um redirecionamento cabeçalho a cabeçalho com o HTTP Status Checker, ou veja o que cada "nove" permite com o Uptime Calculator.
O que é o monitoramento de disponibilidade para SaaS?
O monitoramento de disponibilidade para SaaS consiste em vigiar as partes de um produto de que os clientes dependem — a API pública, os fluxos de login e registro, e as tarefas em segundo plano por trás deles — para que a sua equipe seja alertada no momento em que algo falha. Um ping à página inicial continua verde enquanto a sua API deixa de responder, o login falha, ou uma tarefa noturna para.
Verde com o cliente bloqueado
A verificação passa enquanto o serviço que pagam está indisponível — descobre-o num chamado de suporte.
Vigie todas as camadas
As verificações de API, fluxos e tarefas alimentam um único pipeline — a falha chega a um engenheiro, não a um cliente.
Quanta indisponibilidade cada "nove" permite
"99,9% de disponibilidade" soa infalível até se converter em minutos — eis o que cada nível permite.
Abrir a calculadora de indisponibilidade →| Disponibilidade | Indisponibilidade / mês | Indisponibilidade / ano |
|---|---|---|
| 99% | 7h 18m | 3d 15h |
| 99.9% | 43m 49s | 8h 46m |
| 99.95% | 21m 54s | 4h 23m |
| 99.99% | 4m 23s | 52m 35s |
| 99.999% | 26s | 5m 15s |
Perguntas frequentes
01O que é o monitoramento de disponibilidade para SaaS?+
02Qual é a diferença entre isto e simplesmente fazer ping à minha página inicial?+
03Posso monitorar a minha API pública?+
{{variável}} entre passos. Executa com uma frequência até uma vez por minuto em todos os planos, e um passo com falha é reexecutado a partir de até três localizações antes de abrir um incidente. Uma cadeia é a verificação mais pesada de executar, por isso os monitores de API têm o seu próprio limite por plano — os preços têm os números.04Consegue detectar um login ou registro avariado?+
05Posso ser alertado quando uma tarefa em segundo plano deixa de funcionar?+
06Com que rapidez consegue verificar?+
07Posso dar aos meus clientes uma página de estado?+
08Posso restringir um colega de equipe a apenas alguns monitores?+
09Suportam SSO, e posso obter relatórios de SLA?+
10Que canais de alerta a minha equipe pode usar?+
11Preciso instalar alguma coisa na minha aplicação?+
curl para o URL de ping); o monitoramento de usuários reais é um pequeno snippet de JavaScript. Sem agente, a menos que também queira métricas de servidor.A sua API, fluxos e tarefas, sob vigilância
Coloque a sua API, o fluxo de login e as tarefas em segundo plano sob vigilância ainda esta tarde — e deixe de saber de interrupções através dos clientes.