Monitorização de disponibilidade para SaaS — sabe antes do primeiro pedido de assistência.
A Uptimia atribui à sua API pública, ao fluxo de início de sessão e à tarefa de faturação da noite anterior uma verificação própria a cada uma, em vez de adivinhar a partir de uma página inicial que continua a carregar. Uma falha é confirmada a partir de mais do que uma região antes de notificar quem estiver de prevenção — no Slack, PagerDuty ou onde a sua equipa 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 a decorrer 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 registo 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 são todos 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 painel pode carregar enquanto a API pública deixa de responder, o início de sessão falha ou a tarefa de faturação 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 pedido de assistência 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á a vigiar o endpoint.↓ minuto a minuto
Uma interrupção de API, do início ao fim
O endpoint da conta deixou de funcionar. O painel continuou a carregar, o ping da página inicial manteve-se verde, e todas as integrações que chamavam esse endpoint já estavam a falhar.
Isto cobre a API. Mas um SaaS falha em quatro camadas — aplicação, API, fluxos, tarefas — e cada uma falha por si.↓ cada camada
Todas as camadas do seu produto, vigiadas
As verificações testam a sua API e as suas páginas, um browser real reproduz o início de sessão e o registo, as suas tarefas enviam pings, e um snippet reporta o que os utilizadores reais obtiveram — tudo a chegar a um único painel, numa única lista de contactos.
Feito para a forma como um SaaS falha
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 contra a sua API pública, com uma frequência até uma vez por minuto: iniciar sessão, 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
- Inicia sessão primeiro — inicia sessão 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
Início de sessão e registo, testados antes dos clientes
Depois de um deploy, a primeira pessoa a tentar iniciar sessão devia ser um robô. A Uptimia reproduz o início de sessão e o registo num browser real a partir de 13 localizações, com uma frequência até a cada 10 minutos, e abre um incidente no momento em que um passo falha — com uma captura de ecrã da página no momento da falha.
- Um browser real — acede à página, preenche os campos, clica, verifica o resultado
- Captura de ecrã 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 faturação que nunca correu
Um cron que morre não avisa — nada parece "em baixo" 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
- Define 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
Uma página de estado no seu domínio
Antes de abrir um pedido de assistência, um cliente procura uma página que diga que já sabem. Coloque uma no seu próprio domínio — o seu logótipo, o emblema da Uptimia desativado — a mostrar o estado em tempo real, 90 dias de histórico e todas as notas de incidentes, com os subscritores a receber 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 & subscritores — agrupe monitores por área, publique atualizações de incidentes e manutenção, notifique subscritores
- Pública ou privada — aberta aos seus clientes, ou protegida por palavra-passe
Um incidente, a sua equipa e a sua página de estado
O mesmo incidente confirmado notifica quem estiver de prevenção e atualiza a página que os seus clientes já estão a atualizar.
Microsoft Teams12 canais de alerta, uma única lista de contactos — 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 a si.Não aos 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 a monitorização de SaaS em três passos
Os caminhos críticos do seu produto podem ficar sob vigilância 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 utilizadores reais sentem
Um snippet JavaScript passivo reporta os tempos de carregamento dos visitantes 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
A lançar uma versão? Agende a janela — as verificações pausam, os alertas ficam em silêncio, a página de estado mostra o trabalho planeado.
Um incidente, um alerta
Uma tempestade de alertas torna-se um único resumo, não uma centena de pings — com uma ligação assinada para confirmar e o MTTA registado.
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 a depuração seguinte
Trace um redirecionamento cabeçalho a cabeçalho com o HTTP Status Checker, ou veja o que cada "nove" permite com a Uptime Calculator.
O que é a monitorização de disponibilidade para SaaS?
A monitorização de disponibilidade para SaaS consiste em vigiar as partes de um produto de que os clientes dependem — a API pública, os fluxos de início de sessão e registo, e as tarefas em segundo plano por trás deles — para que a sua equipa seja alertada no momento em que algo falha. Um ping à página inicial mantém-se verde enquanto a sua API deixa de responder, o início de sessão falha, ou uma tarefa noturna para.
Verde enquanto os clientes ficam bloqueados
A sua verificação passa enquanto aquilo que os clientes pagam está em baixo — descobre através de um pedido de assistência.
Vigia 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 disponibilidade →| 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 |
FAQ de monitorização de SaaS
01O que é a monitorização de disponibilidade para SaaS?+
02Em que é que isto é diferente de simplesmente fazer ping à minha página inicial?+
03Posso monitorizar 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 detetar um início de sessão ou registo avariado?+
05Posso ser alertado quando uma tarefa em segundo plano para?+
06Com que rapidez consegue verificar?+
07Posso dar aos meus clientes uma página de estado?+
08Posso restringir um colega de equipa a apenas alguns monitores?+
09Suportam SSO, e posso obter relatórios de SLA?+
10Que canais de alerta a minha equipa pode usar?+
11Preciso de instalar alguma coisa na minha aplicação?+
curl para o URL de ping); a monitorização de utilizadores 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 início de sessão e as tarefas em segundo plano sob vigilância ainda esta tarde — e deixe de saber de interrupções através dos clientes.