Monitoramento
Monitores de uptime
Os monitores verificam as coisas de fora do seu app em um cronograma e alertam quando mudam de estado. Sete tipos compartilham a página de Uptime. Nenhum deles precisa de código, exceto os heartbeats, nos quais o seu job faz ping.
1Escolha um tipo
HTTP: 2xx ou 3xx conta como no ar, opcionalmente exigindo uma palavra-chave no corpo e um limite de tempo de resposta. Heartbeat: seu cron job faz ping em uma URL secreta; atraso significa fora do ar. SSL: handshake TLS em host:port, a cadeia deve ser confiável, mostra emissor e expiração. Domínio: expiração do registro via RDAP, mostra o registrador. TCP: conecta em host:port e fecha. DNS: A, AAAA, CNAME, MX ou TXT por 1.1.1.1 e 8.8.8.8, opcionalmente exigindo um valor. Navegador: uma lista de etapas executada em Chromium headless.
2Intervalos
HTTP a cada 1, 3, 5, 10, 30 ou 60 minutos. Heartbeats de 1 minuto a 24 horas com uma tolerância de 1 a 60 minutos. SSL e domínio a cada 1, 6, 12 ou 24 horas. Verificações de navegador a cada 5 a 60 minutos.
3Etapas da verificação de navegador
Até 20 etapas como dados, nunca código. A etapa 1 deve ser goto. Ações: goto (url), click (selector), fill (selector, value), expect_text (text), expect_selector (selector), wait (ms). Seletores e textos de até 300 caracteres, valores 500, esperas de 10 s cada e 30 s no total, a execução inteira 60 s. Em caso de falha, uma captura de tela da página é guardada abaixo da linha. Use uma conta de teste para os valores de fill; eles são armazenados em texto simples.
[
{ "action": "goto", "url": "https://shop.example.com/login" },
{ "action": "fill", "selector": "#email", "value": "monitor@example.com" },
{ "action": "fill", "selector": "#password", "value": "test-only" },
{ "action": "click", "selector": "button[type=submit]" },
{ "action": "expect_text", "text": "Your orders" }
]4Como se decide que está fora do ar
Uma verificação com falha é repetida após 20 segundos e uma região só está falhando na segunda falha consecutiva. Um monitor com várias regiões só está fora do ar quando uma maioria estrita está falhando (1 de 1, 2 de 2, 2 de 3). Verificações de domínio e navegador usam uma região. Cada queda e cada recuperação gera um alerta pelos seus canais ou para os proprietários.
Bom saber
- Limites por plano: HTTP, SSL, domínio, TCP e DNS compartilham um pool de 10 (Free), 25 (Solo), 100 (Team), 500 (Scale); os heartbeats têm os mesmos números em um pool próprio; verificações de navegador são 0, 3, 20 e 100.
- Avisos extras: monitor.slow e monitor.fast quando o p95 das últimas 10 verificações HTTP cruza o limite de tempo de resposta; monitor.expiring aos 14, 7 e 1 dias para certificados e 30 e 7 dias para domínios, uma vez por limite.
- Endereços privados e internos (localhost, 10.x, .local, .internal e afins) são recusados ao salvar. Registros sem RDAP, como .io, permanecem no ar e informam que a data de expiração não está disponível.
- O uptime é exibido para 24 horas e 30 dias. Os resultados brutos das verificações são mantidos por 3 dias. A URL de heartbeat é exibida uma única vez e pode ser substituída.
Travou? Envie um e-mail para support@blipit.io. As chaves e o DSN exato de cada projeto ficam em Chaves de API no app.blipit.io.

