Saiba que caiu antes do seu cliente saber.

O de uptime faz uma requisição HTTP e responde em três estados: no ar, no ar porém lento, ou fora do ar. É barato — dezenas de alvos a cada minuto, direto do relógio. O de performance abre a página num Chrome de verdade e roda o Lighthouse (performance, boas práticas e SEO): um navegador inteiro por auditoria, numa máquina própria, então o intervalo mínimo é de uma hora e ele sai do relógio para uma fila. A separação existe porque misturar os dois custos no mesmo relógio faria a auditoria lenta atrasar o ping — e um produto de monitoramento que atrasa o alerta é o pior tipo de ironia.

Não, e isso é desenho, não sorte. Um incidente só abre depois de N checagens ruins seguidas — o padrão é 2, e você ajusta — e fecha na primeira boa. A falha isolada que acontece com todo mundo fica registrada no histórico e não vira notificação. Há também o estado "degraded": uma API que responde certo, só que devagar, aparece em âmbar no painel em vez de disparar o mesmo alarme de queda.

De um: um ponto da rede da Cloudflare. Isso tem uma consequência que preferimos escrever antes de você perguntar — uma queda de rede entre nós e o seu servidor aparece como queda sua. Se o seu caso exige distinguir "o mundo inteiro não alcança" de "essa rota está ruim", você precisa de sondas em vários pontos, e isso hoje não existe aqui. Para saber se o seu serviço está de pé e ser avisado quando não estiver, uma sonda basta.

Sim. Você aponta um CNAME de status.suaempresa.com para cname.monitors.myinfrastructure.click e o certificado é emitido automaticamente. Antes do DNS propagar, o endereço /s/<slug> já mostra a página — serve de preview, e o slug leva sufixo aleatório porque "sem indexação" só protege enquanto o link não é adivinhável. A página é HTML renderizado no servidor: aparece completa no primeiro byte, sem depender de JavaScript, de CORS ou de o painel estar no ar. É o requisito mais importante dela, já que ela existe justamente para os momentos em que outras coisas não estão funcionando.

Só saúde e sintoma. Nunca aparecem: a URL do alvo, o nome interno do monitor, os ids, a configuração (que carrega headers de autenticação), o status HTTP, a mensagem de erro crua, o intervalo de checagem e a contagem de checagens. A causa de um incidente passa por um vocabulário fechado, porque a mensagem original costuma trazer a URL interna. O nome público de cada componente é sugerido a partir do HOST da URL, nunca do nome interno: payments.acme.com já é público, payments-api-prod não.

Cor de marca, fonte, tema, texto de rodapé e CSS adicional. Duas exceções, ambas deliberadas. Não há upload de logo: aceitar imagem externa obrigaria a afrouxar a política de segurança e cada visita entregaria o IP do seu cliente a um terceiro. E as cores de estado — verde, âmbar, vermelho — não são configuráveis: elas são vocabulário compartilhado com o resto da web, e um "fora do ar" pintado de verde é uma página que mente com aparência de calma. O seu CSS é podado, não recusado: o que sai é devolvido na resposta, para a tela poder te dizer o que caiu.

90 dias de uptime na barra da página pública, a partir de um resumo diário — uma linha por monitor por dia, cerca de 0,6 MB por ano. Guardar 90 dias de checagens brutas custaria centenas de megabytes e faria cada visita anônima varrer milhões de linhas, então a barra pública lê o resumo. O detalhe fino de cada checagem fica no painel, onde você é quem está olhando.

E-mail, Discord, Telegram e webhook genérico. No e-mail você cola a escala inteira de uma vez — vírgula, ponto e vírgula ou uma coluna de planilha — e todo mundo da lista recebe junto, até 50 endereços. O Discord é um canal próprio, não um webhook genérico apontado para lá: o aviso chega como embed, vermelho quando cai e verde quando volta, com a palavra escrita e não só a cor. Sem SMS, sem ligação e sem rodízio de plantão. O envio nunca bloqueia a checagem: timeout curto, sem retentativa, e o próximo monitor não espera o seu webhook lento. Um alerta que chega cinco minutos depois já não é alerta, e uma fila de retentativas para um endpoint morto viraria trabalho acumulado sem fim. O incidente fica gravado de qualquer forma.

Para qualquer endereço público, sim. Destinos em rede interna são recusados — localhost, 127.x, faixas privadas, .internal e o 169.254.169.254 dos metadados de nuvem. A requisição sai da nossa infraestrutura, então aceitar esses destinos transformaria o serviço num leitor de rede interna a mando de quem cadastra o canal. O mesmo vale nos monitores: você define headers, mas host, content-length e os x-forwarded-* são recusados, porque reescrevê-los não ajuda a monitorar nada e abre uso indevido do serviço como proxy.

Não, e essa distinção custou uma correção. O Lighthouse devolve nota nula quando o Chrome nem carrega a página — DNS morto, certificado interstitial, conexão recusada — e tratar isso como zero produz um alerta dizendo "o LCP piorou" para um domínio que sequer resolve, mandando você investigar a coisa errada. Aqui esse caso é um estado próprio: erro, não nota baixa.

Tem, na revisão 2026-07-28 — a mesma dos outros seis. O endereço é o da conta inteira, sem id no caminho: a sua chave mk_ já alcança todos os seus monitores, então um recorte só para o MCP inventaria uma noção de posse que a API REST não tem. É o mesmo desenho do Hoster e do Functions; Auth, Storage, Payments e Messages recortam no path porque neles uma pessoa administra vários recursos. São 18 ferramentas, e o escopo do token decide quais aparecem: com auth:read as nove de escrita não entram sequer na lista. A documentação completa está no /llms-mcp.txt.

R$ 29,99 no Starter (3 monitores e 1 página de status), R$ 49,99 no Pro (9 monitores, 3 páginas, Web Performance e domínio próprio) e R$ 99,99 no Scale (199 monitores e páginas de status sem teto). No anual você paga 10 meses e leva 12. Os preços desta página vêm do catálogo em tempo de execução, e não de um número digitado aqui: o que você lê é exatamente o que a Stripe cobra. Uptime, estado degradado, incidentes por confirmação e alertas por e-mail, Discord, Telegram e webhook estão em todos os planos, inclusive no Starter.

Não. O gate de plano falha ABERTO de propósito: sem resposta do Payments, por timeout ou por configuração ausente, ele libera. Esse limite protege receita, não protege o dado de ninguém — quem separa cliente de cliente é a autenticação. Um gate de cobrança que fecha quando a cobrança cai transforma um incidente nosso em incidente de todos os clientes, e num produto de monitoramento isso é especialmente grave: você perderia a visibilidade exatamente durante um incidente.