Os sete produtos
Antes de decidir
Como nos comparamos
vs. Supabase
Postgres gerenciado, fatura em dólar
vs. Clerk
Login pronto, suporte em outro fuso
vs. Stripe
Cobrança global, assinatura como evento
Se o seu produto é global e cobra em dólar, as ferramentas de lá provavelmente são a escolha certa.
Infraestrutura RiLiGar · Monitors
Saiba que caiu antes do seu cliente saber.
Uptime de API e nota de performance no mesmo painel. O alerta chega por e-mail, Discord ou Telegram depois de duas falhas seguidas — não de um soluço de rede — e a página de status pública, no seu domínio, responde ao seu cliente enquanto você conserta.
Comece de graça, sem cartão. O primeiro monitor leva um minuto: cole a URL, escolha o intervalo e pronto.
Por que isso existe
Hoje, quem descobre a queda é
O CLIENTE.
Ele liga, manda mensagem, abre um chamado. Nesse ponto o prejuízo já aconteceu duas vezes: o serviço ficou fora do ar e alguém de fora precisou avisar. A inversão dessa ordem é o produto inteiro — e ela não exige que você monte relógio, banco de histórico e canal de aviso para conseguir.
- O cron que avisa no terminal que ninguém está lendo às 3h
- O alerta que cria lobo: dispara tanto que virou ruído ignorado
- O suporte respondendo um a um enquanto o incidente ainda está aberto
O caminho inteiro
Checa, mede, avisa, publica.
Quatro etapas — e nenhuma delas é montar infraestrutura.
1 · Uptime
Uma requisição, três respostas possíveis
No ar, fora do ar — e no ar porém lento, que é um estado próprio. Acordar alguém às 3h por uma API que responde certo e devagar é exatamente como se perde a confiança num alerta.
kind: http url: https://api.acme.com/health intervalo: 30s · 1m · 5m · 10m · 30m · 1h → up respondeu como esperado → degraded certo, acima do limiar → down não respondeu
2 · Performance
Lighthouse de verdade, num Chrome de verdade
Performance, boas práticas e SEO com o navegador abrindo a página. Cada auditoria sobe um Chrome, custa ~130 MB e leva dezenas de segundos — por isso ela entra numa fila de uma por vez, e nunca disputa espaço com os pings.
kind: web url: https://acme.com intervalo: 1h · 6h · 12h · 24h → performance · best-practices · seo → fila serial de 1
3 · Alerta
Duas falhas seguidas, não uma
Um incidente abre depois de N checagens ruins em sequência (padrão 2) e fecha na primeira boa. Uma falha isolada — o timeout de rede que acontece com todo mundo — não vira notificação, e é isso que faz o alerta continuar significando alguma coisa.
check 1 down → nada ainda
check 2 down → incidente ABERTO
↓
e-mail
Discord
Telegram
webhook
check 3 up → incidente FECHADO4 · Página pública
O status no domínio do cliente, com a cara dele
Cor, fonte, tema e rodapé são seus; o endereço também. Você aponta um CNAME e o certificado é pedido automaticamente — durante um incidente, a página responde por você enquanto o suporte ainda está lendo o alerta.
status.acme.com CNAME → monitors-manager.fly.dev ✓ certificado pedido sozinho ✓ HTML pronto no primeiro byte ✓ 90 dias de histórico antes do DNS: /s/<slug>
As duas famílias
Custos diferentes em
ORDENS DE GRANDEZA.
Um ping é ~1 KB e dezenas de milissegundos; uma auditoria Lighthouse sobe um Chrome, come ~130 MB e leva dezenas de segundos. Tratar os dois como a mesma tarefa faz duas auditorias simultâneas disputarem espaço com os pings até o sistema derrubar a máquina inteira. Aqui a auditoria entra numa fila de uma por vez, e o ping — que é barato — nunca entra nessa fila.
- Uptime a partir de 30s; performance a partir de 1h
- Um relógio só, no processo primário — não um por worker
- Um tick varre quem venceu, em vez de um timer por monitor
- Jitter espalha a carga, para 300 monitores não dispararem juntos
A página de status
Ela existe para o dia em que as outras coisas não funcionam.
É a única parte do produto que o seu cliente vê. Por isso ela é HTML do servidor, no seu domínio, e não uma tela que depende de tudo estar de pé para aparecer.
As decisões que ela carrega
- HTML pronto no primeiro byte a página aparece completa sem depender de CORS, de JavaScript ou de o painel estar no ar. Justamente quando algo caiu, é o que não pode cair junto.
- Falha preservando o último estado bom se a atualização automática quebra, o cabeçalho se marca como defasado em vez de esvaziar a tela. Uma página de status em branco no meio de um incidente é a pior saída possível.
- Grupo assume o estado do filho mais degradado 11 componentes no ar e 1 fora não pode aparecer verde. A barra de 90 dias do grupo usa o PIOR uptime de cada dia — na média, uma queda entre onze saudáveis vira 99,2% e some.
- Abre sozinha no problema os grupos vêm colapsados, menos os que não estão no ar — decidido no servidor, com `<details>` nativo. Com JavaScript desligado, tudo continua acessível.
- Verde, âmbar e vermelho não são configuráveis cor, fonte, tema e rodapé são do cliente. As cores de ESTADO não: um cliente pintando "fora do ar" de verde produziria uma página que mente com aparência de calma.
O que ela nunca mostra a URL do alvo, o nome interno do monitor, os ids, a configuração com seus headers de autenticação, o status HTTP, o erro cru, o intervalo e a contagem de checagens. A causa de um incidente passa por um vocabulário fechado — a mensagem original costuma trazer a URL interna junto.
O que sai e o que fica
Sua página, sem o seu mapa.
Quem abre uma página de status está, por definição, com um problema.
Sem terceiros na página
Nenhuma conexão sai para fora
A fonte da marca vai embutida no próprio HTML, não vem do Google Fonts como nos painéis da suíte. Não há upload de logo, porque aceitar imagem externa entregaria o IP de cada visitante a um terceiro. A página não conta a ninguém quem a está visitando.
default-src 'none' font-src data: script-src 'sha256-…' → sem CDN → sem Google Fonts → sem logo externo
Sem número comercial
Saúde e sintoma. Nada além disso.
O nome público é sugerido a partir do HOST da URL, nunca do nome interno — payments.acme.com já é público, payments-api-prod não. E o seu CSS é podado em vez de recusado: uma folha de 40 linhas não é rejeitada inteira por uma linha, e a resposta diz o que caiu.
público: "API de Pagamentos"
estado: degradado
uptime: 99,4% (90 dias)
nunca: url · id · status HTTP
erro cru · intervalo
config · nome internoSendo justo
Um cron resolve "subiu?".
O difícil é tudo o que vem depois.
O cron que você já tem
Onde ele já resolve sozinho
Um curl a cada minuto, de graça
Ele tem
Você escolhe exatamente o que testar
Ele tem
Roda dentro da sua rede, sem expor nada
Ele tem
Zero fornecedor, zero contrato
Ele tem
Fique com ele se
Um aviso no seu terminal já basta
Para quem só quer saber se subiu, o cron resolve — e continua ao seu lado.
RiLiGar Monitors
A parte que o cron não faz: guardar o histórico, distinguir lento de fora do ar, não te acordar por um soluço de rede e responder ao seu cliente numa página pública enquanto você conserta.
- Uptime de API e nota de performance no mesmo painel
- "No ar porém lento" é um estado, não um alarme falso
- Incidente só depois de 2 falhas seguidas — e fecha sozinho
- Alerta por e-mail, Discord, Telegram e webhook, sem segurar a checagem
- Página de status no SEU domínio, com a sua cara
- 90 dias de histórico sem varrer milhões de linhas
Model Context Protocol
Seu agente investiga a queda. Sem abrir o painel.
Olhar o gráfico é a parte fácil; o que faltava era responder o que vem depois dele — o que aconteceu, quando começou, e já normalizou. São 14 ferramentas — 8 leem, 6 escrevem — na revisão 2026-07-28, a stateless. O endereço vale para a conta inteira: a chave já cobre todos os seus monitores, então não há id no caminho.
O que o servidor NÃO oferece
- Apagar monitor ou página de status não existem como ferramenta. Aqui isso pesa mais que nos outros produtos: apagar o monitor apaga junto o histórico que provaria o incidente.
- Cadastrar canal de alerta ou domínio próprio continuam no painel, onde há uma pessoa confirmando. Um destino de alerta escolhido por agente é superfície de exfiltração — o alerta passaria a sair para um endereço que ninguém escolheu.
- E o plano continua valendo criar monitor e criar página passam pelo mesmo limite da API. Estourou o plano, a chamada falha dizendo quanto cabe — o agente reporta em vez de insistir.
Autentica das duas formas com a sua mk_ ou com OAuth 2.1 pelo RiLiGar Auth. As duas chegam na mesma conta.
Como o agente entra
Nenhuma chave no arquivo.
O token nasce no navegador, e o escopo decide o que ele enxerga.
OAuth 2.1
Você aprova no navegador, uma vez
Sem header nenhum no comando. Na primeira chamada o servidor responde 401 apontando para o metadata; o cliente descobre o authorization server sozinho, abre o navegador e você aprova. O escopo do token decide o catálogo: com auth:read ele enxerga 8 ferramentas, e as 6 de escrita não aparecem sequer na lista. Em CI, onde não há navegador, a sua mk_ conecta direto.
$ claude mcp add --transport http \
riligar-monitors \
https://monitors.manager.myinfrastructure.click/mcp
→ 401 WWW-Authenticate
→ descobre o auth server
→ abre o navegador
✓ token com aud= esta conta ▊O que muda na prática
A pergunta que vem depois do gráfico
O agente não lê a lista crua de checagens — ela repete a mesma informação centenas de vezes. Ele pede os episódios, que dizem quando começou, quando acabou e por quê, e confirma na hora se já normalizou.
Você: "o checkout caiu ontem à noite? por quanto tempo?" → monitors_list acha o id do monitor → monitors_get_episodes início, fim e causa de cada episódio → monitors_check_now confirma se já normalizou ▊
A régua
Os cinco eixos que decidem a escolha
A mesma tabela em toda página de produto da RiLiGar. Duas linhas aqui são limitações, escritas com a mesma tinta das outras — ela existe para você decidir rápido se o encaixe é seu.
O que é checado
Duas famílias, um painel
Uptime de API por requisição HTTP (a partir de 30s) e auditoria Lighthouse com Chrome real (a partir de 1h). São custos diferentes em ordens de grandeza — ~1 KB contra ~130 MB e um navegador —, e por isso intervalos mínimos diferentes.
De onde sai a checagem
Uma região, sem réplica
Uma VM na Fly, em iad. Isso significa que uma queda de rede entre nós e você aparece como queda sua — quem precisa distinguir incidente global de rota ruim precisa de sondas em vários pontos, e isso hoje não existe aqui.
Quando o alerta dispara
Depois de 2 falhas seguidas
Configurável. Fecha na primeira checagem boa. O envio nunca segura o relógio: timeout curto, sem retentativa, e o incidente fica gravado de qualquer jeito — o painel é a fonte da verdade, o alerta é a conveniência.
Para onde o alerta vai
E-mail, Discord, Telegram e webhook
A lista de e-mails aceita a escala inteira colada de uma vez — vírgula, ponto e vírgula ou uma coluna de planilha. Sem SMS, sem ligação, sem rodízio de plantão: quem está na lista recebe junto. Destinos em rede interna (localhost, 169.254.169.254, faixas privadas) são recusados: a requisição sai da nossa VM, e aceitá-los seria transformar o serviço em leitor de rede a mando de quem cadastra o canal.
Integração com agente
MCP, 14 ferramentas
Servidor MCP na revisão 2026-07-28, autenticando por OAuth 2.1 — você aprova no navegador, sem chave no arquivo. Oito ferramentas leem e seis escrevem; nenhuma apaga — nem monitor, nem página de status. Cadastrar canal de alerta e domínio próprio também ficam fora, e continuam no painel.
Se algum destes pontos não bater no seu caso, escreva. A gente confere e corrige a linha.
Preço
1, 5 ou ilimitados monitores
FAQ
As objeções, na ordem em que elas aparecem
Achou um limite que não está escrito aqui?
Fala direto com quem escreveu o código. Se você encontrou onde quebra, a gente quer publicar isso antes do próximo visitante descobrir sozinho.
Cole a URL, escolha o intervalo. Leva um minuto.
Sem cartão. Se o seu serviço cair hoje à noite, quem te avisa é o alerta — não o seu cliente.