Monitoramento de sites para programadores, integrado na sua stack.
A Uptimia executa as suas chamadas de API reais — iniciar sessão, obter o token, colocar a encomenda, voltar a consultá-la — e verifica cada resposta. Dê a cada cron job um URL de heartbeat, crie monitores a partir do seu script de deploy e receba alertas no Slack, Discord ou PagerDuty.
Step breakdown
All 4 steps passedFailed at step 31.66 s · 14:251.38 s · 14:327-day averagesLast runAssertions — step 3
3 of 3 passing1 of 3 passedResponse — step 3
201 · 624 ms500 · 612 msRecent Runs
every 5 min · 12 locations
New York✗ Failed at step 31.41 s
Frankfurt✗ Failed at step 31.38 s
London✓ All 4 steps passed1.62 s
Sydney✓ All 4 steps passed1.71 sNew York✓ All 4 steps passed1.58 s
Tokyo✓ All 4 steps passed1.64 sQuatro falhas que não geram exceção
As quatro são verdadeiras no dia do deploy. Nenhuma delas se mantém verdadeira sozinha — e quando uma deixa de o ser, nada gera uma exceção.
"Se algo tivesse quebrado, veríamos uma exceção."
Os rastreadores de erros só veem código que é executado. Uma entrada cron que nunca arranca, um worker encravado a meio de uma tarefa, um certificado que expira silenciosamente — nenhum deles gera uma exceção. As piores falhas não são stack traces; são silêncio.
"O pipeline está verde, por isso a produção está bem."
A CI prova que o código estava bom no momento do deploy. Tokens expirados, discos cheios, quotas esgotadas e configurações desalinhadas acontecem todos entre deploys — no sistema em execução que a sua suite de testes nunca mais volta a ver.
"Ficaríamos a saber depressa — estamos online o dia todo."
Está ao teclado 40 das 168 horas da semana — ninguém está a vigiar as outras 128. E os usuários raramente reportam um checkout avariado; tentam uma vez e vão-se embora.
"Funcionou em staging, por isso funciona."
O staging nunca tem o tráfego, o volume de dados, as quotas de terceiros ou o DNS da produção. Os modos de falha que o alertam às 03:00 são precisamente aqueles que o staging não consegue reproduzir.
"Temos um endpoint /health — estamos cobertos" é a maior de todas. Uma verificação de estado a cada minuto diz-lhe 1 440 vezes por dia que um processo responde (24 × 60). O número dessas verificações que prova que o checkout se completa, que a cópia de segurança noturna correu ou que a fila está a esvaziar: zero.
"Um processo responde" e "o sistema funciona" são afirmações diferentes — e só uma delas é a que interessa aos seus usuários.
Assim fica um cron job que morreu em silêncio, com um heartbeat escutando.↓ minuto a minuto
Quando um cron job para em silêncio
Um deploy reescreveu o crontab e perdeu uma linha. Nessa noite, o worker de faturas não arrancou, não gerou nenhum erro e todos os painéis mantiveram-se verdes — a fila nunca se mexeu.
Isto resolve a tarefa que morreu. Mas o cron é apenas uma das superfícies que falham em silêncio — cada crença acima tem a sua.↓ um monitor para cada uma
Cadeias, pings e agentes
Cadeias de API para serviços, pings de entrada para tarefas, fluxos em navegador real para checkouts, um agente de uma linha para a máquina. Superfícies diferentes, um único fluxo de incidentes, uma única API.
Cadeias, heartbeats e escalonamentos
Cada passo da cadeia, verificado
Um endpoint /health prova que um processo responde. Não prova nada sobre o fluxo por trás dele. A cadeia executa as chamadas reais por ordem e verifica cada resposta — o código de estado, o tempo que demorou, um valor dentro do JSON — até uma vez por minuto, em qualquer plano pago, a partir de todas as localizações ou apenas das que escolher.
- Até 15 passos — GET, POST, PUT, PATCH, DELETE ou HEAD, executados por ordem
- Extrair e reutilizar — retire um valor de uma resposta e insira-o na seguinte com
{{token}} - Verifique o que importa — código de estado, tempo de resposta, um valor JSONPath, um cabeçalho ou texto no corpo, por passo
/health responde bem durante todo este tempo — e não prova nenhuma destas quatro chamadas.
0 de 4 comprovadas
A tarefa que nunca arrancou
Uma tarefa que deixa de correr fica silenciosa, não vermelha — nada gera uma exceção, por isso nada alerta. Dê-lhe um URL de heartbeat para enviar um ping quando corre, e o ping em falta transforma-se no alarme: perca a janela para além do período de tolerância e a Uptimia abre um incidente. Sinalize também o início e o fim, e capta tarefas que ficam presas em vez de pararem.
- Intervalo ou calendário cron — um intervalo simples ou uma expressão cron de 5 campos no fuso horário da sua conta
- Uma linha para integrar — excertos prontos a copiar e colar para Crontab, Bash, PowerShell, GitHub Actions e PHP
- Deteta bloqueios, não só falhas de ping — envie um ping de início e um limiar de duração assinala uma tarefa que nunca termina
Monitores criados a partir do seu passo de deploy
Ninguém clica em nada — o script que lançou o serviço criou o respetivo monitor. Crie e faça a gestão de monitores através da API REST a partir de um passo de CI, e quando um incidente é aberto, um webhook personalizado envia-o por POST para o que já utiliza: um painel de estado, um bot, um fluxo de ChatOps.
- Uma API REST — crie, leia, atualize e exclua monitores em todos os planos (os monitores de API e os heartbeats residem na v2), com chaves de API da conta geridas nas configurações
- Webhooks personalizados — envie por POST um corpo JSON fixo com os seus próprios cabeçalhos para qualquer endpoint num evento de monitor
- Seguro por predefinição — a entrega do webhook é verificada por TLS, fixa o DNS no momento do envio e rejeita destinos de rede privada
curl -X POST …/api/v2/api-monitor
-d '{"name":"Checkout API","interval":60}'
Primeiro no Slack, PagerDuty se ninguém confirmar
No canal que a sua equipe já vigia, não numa caixa de entrada que ninguém abre durante a noite. O escalonamento leva um ping do Slack sem resposta até um alerta no PagerDuty, no calendário que definir, e uma única confirmação — feita no próprio alerta, sem sessão iniciada — pausa todos os passos pendentes para todos.
- Alertas onde trabalha — Slack, Discord, Telegram, MS Teams, Mattermost, PagerDuty, e-mail, SMS, webhooks e mais
- Escalonamentos — até 10 passos temporizados por política; confirme a partir do alerta e o escalonamento pausa
- Confirmado primeiro — as interrupções são verificadas a partir de várias regiões — e as tarefas atrasadas para além do período de tolerância — antes de alguém ser notificado
Alertado onde já trabalha, não noutro painel
Um worker que parou, uma cadeia que quebrou, uma máquina sem espaço em disco — tudo isto chega aos mesmos canais, e tudo isto é programável a partir da API REST.
Microsoft TeamsUma lista de contatos — configure-a a partir da API ou da interface, uma única vez.
Ver o diretório completo de integrações →Um deploy malsucedido devia alertá-lo.Não os seus usuários.
O teste de 30 dias desbloqueia todos os tipos de monitor e todos os canais de alertas.
Configure o seu primeiro monitor em três passos
Aponte-o para uma superfície, encaminhe o alerta e deixe-o a funcionar.
Escolha a superfície
Uma cadeia de API, um URL de heartbeat, um fluxo em navegador ou o agente de uma linha — crie-o na interface ou através da API REST.
Encaminhe o alerta
Envie-o para o Slack, Discord ou PagerDuty, adicione um webhook e decida quem é alertado a seguir se ninguém confirmar.
Deixe-o funcionando
As verificações são executadas a partir de mais de 171 sondas e confirmam uma falha antes de o alertar — identificando o passo ou a tarefa que falhou.
Também incluído
Agente de servidor de uma linha
CPU, memória, disco e carga a partir de dentro da máquina — uma instalação bash verificada por checksum, sem coletor para escrever. Linux, através de um temporizador systemd ou cron.
Monitoramento de transações
Reproduza um início de sessão ou checkout num navegador real — criado passo a passo no construtor, com uma captura de tela do que cada passo viu.
Janelas de manutenção
Vai fazer deploy esta noite? Agende a janela — as verificações pausam, os alertas ficam em silêncio, sem falsos alarmes durante um lançamento planeado.
Avisos de recuperação
Quando um serviço volta a funcionar, as pessoas que foram alertadas também são informadas — sem deixar um "ainda está em baixo?" a pairar no canal.
Histórico de incidentes
Todos os incidentes ficam registados com o que acionou, quando, quanto tempo demorou a recuperação e — quando há um escalonamento em curso — quem o confirmou.
Uma lista para cadeias e tarefas
Cadeias de API, heartbeats, servidores e verificações de disponibilidade compartilham um único painel, uma única espinha dorsal de alertas e uma única API — não quatro ferramentas separadas.
O que é o monitoramento de sites para programadores?
O monitoramento de sites para programadores é a prática de vigiar as superfícies que lança — APIs HTTP, tarefas em segundo plano, servidores e fluxos de usuário — e alertá-lo através das ferramentas que já utiliza quando uma delas falha. O monitoramento é integrado na stack: uma verificação de API com vários passos a partir do exterior, um ping de heartbeat que um cron job envia, um agente dentro da máquina, e uma API REST e webhooks onde preferir programá-la.
Responde, e continua avariado
Um ping superficial mantém-se verde enquanto o fluxo de que os seus usuários dependem falha.
A cadeia deteta-o
A verificação que falha identifica a chamada exata — para começar a depurar, não a adivinhar.
Que monitor vigia o quê
Cada família vigia uma superfície diferente — todas a compartilhar um único painel, uma única espinha dorsal de alertas e uma única API REST. Cada uma é também contabilizada em separado, e uma cadeia é a linha mais dispendiosa de executar — a página de preços tem os números por plano.
Ver todos os tipos de monitor →| Superfície | O que detecta | Como funciona |
|---|---|---|
| Cadeia de API | Fluxos com vários passos quebrados | Até 15 passos ordenados com verificações por passo, com uma frequência de até uma vez por minuto |
| Heartbeat | Cron & workers que param silenciosamente | URL de ping de entrada; uma janela falhada além do período de tolerância abre um incidente |
| Disponibilidade | Interrupções do serviço, erros de servidor | Verificações externas com uma frequência de até 30 s no plano Professional e superiores, confirmadas a partir de até 3 regiões |
| Agente de servidor | Pressão de CPU, memória e disco | Agente Linux de uma linha, a reportar /proc + df a cada 30 s |
| Transação | Inícios de sessão & checkouts avariados | Fluxos com vários passos reproduzidos num navegador real |
Perguntas frequentes
01O que é o monitoramento de sites para programadores?+
02É possível monitorizar um fluxo de API com vários passos, e não apenas um endpoint?+
{{token}}, e verifique o código de estado, o tempo de resposta, um valor JSONPath, um cabeçalho ou texto no corpo por passo. Se um passo falhar, o alerta identifica-o — sabe exatamente qual chamada falhou.03Como monitorizar um cron job ou um worker em segundo plano?+
curl para que envie um ping quando corre. Defina um intervalo ou um calendário cron com um período de tolerância, e se o ping não chegar, um incidente é aberto. Um ping de início mais um limiar de duração também captam tarefas que ficam presas. Os excertos cobrem Crontab, Bash, PowerShell, GitHub Actions e PHP.04Existe uma API de monitoramento de disponibilidade para criar e gerir monitores?+
curl pronto a copiar. Não existe nenhum provedor Terraform nem aplicação Zapier.05É possível emitir uma chave de API separada para cada membro da equipe?+
06Para onde vão os alertas, e posso encaminhá-los para minhas ferramentas?+
07É feita a gestão de escalas de prevenção?+
08O agente de servidor funciona no Windows?+
/proc e df para CPU, memória, disco e carga. Um coletor em PowerShell para Windows e um para macOS são lançados em conjunto e enviam a mesma carga útil — sem os valores por núcleo e de espera de I/O que só o Linux expõe — mas não são disponibilizados como uma linha única. As máquinas Windows também podem ser vigiadas a partir do exterior com monitores de disponibilidade, API ou transação.09Posso importar um comando cURL ou uma especificação OpenAPI no construtor?+
10Quantas cadeias, heartbeats e agentes inclui um plano?+
Lance-o. Ficamos de olho.
Integre uma cadeia de API, um heartbeat e um agente de servidor no teste — os alertas chegam até si onde já está.