Monitoramento como código: suas verificações de uptime num PR

Abra o seu painel de monitoramento e conte as verificações que ninguém sabe explicar. A do intervalo de 47 segundos: por que 47? As duas que ainda apontam para uma máquina de staging desativada em março. A verificação HTTP que está amarela há tanto tempo que a equipe inteira já lê amarelo como verde. Alguém criou cada uma delas de propósito, um dia. Depois essa pessoa mudou de equipe, ou saiu da empresa, e o raciocínio foi embora junto com ela.

É isso que clicar em botões faz com o monitoramento. A configuração é real, segura o peso de muita coisa e não está em nenhum lugar onde você consiga lê-la. Você não consegue fazer um diff dela, não consegue revisá-la, não consegue perguntar ao git blame quem definiu aquele timeout e o que tinha na cabeça. O monitor deveria ser aquilo em que você confia quando todo o resto está pegando fogo, e você o construiu sobre uma pilha de cliques sem documentação.

Então leve isso para o controle de versão. Não porque infraestrutura como código seja uma virtude para colecionar, mas porque um monitor é exatamente o tipo de configuração discreta e duradoura que vira um passivo no momento em que fica invisível.

Em resumo

Um monitor criado com cliques num painel não tem diff, nem histórico, nem registro do porquê. Leve-o para um repositório e cada mudança vira um pull request revisado, rastreável com git blame; uma região nova vira um único apply, em vez de uma tarde clicando. O preço é um arquivo de estado para manter. O Uptimepage dá suporte a isso via Terraform, uma API REST e MCP.

O que o “como código” traz de verdade

Não é a digitação. Declarar um monitor em HCL exige mais teclas do que clicar em “nova verificação”, e quem diz que o ponto é digitar nunca manteve mais do que três deles.

O ponto é o pull request. Quando um monitor mora num repositório, mudá-lo passa a ser algo que uma segunda pessoa olha antes de valer. “Por que estamos baixando para dez segundos o intervalo da verificação de pagamentos?” é uma conversa muito melhor de ter num PR do que num postmortem. Você ganha um diff e ganha histórico. Você consegue subir uma região novinha e reproduzir quarenta monitores num único apply, em vez de passar quarenta tardes clicando. E quando a pessoa que definiu o limite vai embora, o limite e o motivo dele ficam no arquivo.

Este é o mínimo que funciona, com o provider do Terraform do Uptimepage:

terraform {
  required_providers {
    uptimepage = {
      source = "uptimepage/uptimepage"
    }
  }
}

resource "uptimepage_target" "api" {
  name     = "api prod"
  interval = 60

  check = {
    type = "http"
    http = {
      url = "https://api.example.com/healthz"
      expected_status = {
        kind  = "exact"
        exact = 200
      }
    }
  }
}

Repare que o bloco check é aninhado, e não uma pilha plana de campos. Você define type = "http" e depois preenche um http = { ... }. É uma escolha deliberada de esquema, e uma boa escolha: um recurso plano, com url, port, host, record_type e cert_days todos pendurados no nível superior, deixaria você escrever um absurdo, como uma verificação TCP com um matcher de status HTTP, e só descobrir na hora do apply. O formato aninhado torna os estados inválidos impossíveis de representar. Você só consegue definir os campos de http quando o tipo é http. Fica um pouco verboso, e poupa você de uma categoria de erro que a versão plana deixa acontecer.

A parte que o guia rápido pula

Todo tutorial de Terraform para em “e agora rode o apply”. Aqui vão três coisas que eles não contam, mais ou menos em ordem de quanto vão morder você.

O estado, não o painel. O Terraform registra o que ele acredita que existe. Mude um intervalo na interface web e o Terraform não fica sabendo; o próximo plan propõe, todo animado, reverter a sua edição manual para o que o código diz. Isso é o comportamento esperado: depois que um monitor está em código, o código manda, e clicar pelo painel vira drift que o Terraform vai desfazer em silêncio. Decida isso de antemão. Rode terraform plan -refresh-only para ver o drift antes que ele pegue você de surpresa.

Apagou o bloco, apagou o monitor. Tire aquelas oito linhas do seu arquivo .tf, rode o apply, e a verificação real para de rodar. Em silêncio. Para a maioria dos recursos, tanto faz. Para o que vigia a sua API de produção, “limpei uma configuração e ficamos uma semana sem monitorar os pagamentos” é uma frase que gente de verdade já disse em voz alta. Eu já cheguei mais perto de dizê-la do que gostaria. Trate um monitor removido com a mesma desconfiança que uma tabela apagada, porque o raio de impacto é o mesmo: você não percebe até que quebre aquilo que deixou de vigiar.

Segredos no estado. Se a sua verificação precisa de autenticação básica ou de um token, esse valor tem que chegar ao provider de algum jeito, e o que você passar é gravado no arquivo de estado em texto puro, à vista de qualquer pessoa com acesso de leitura ao backend. O provider marca a senha como sensitive, e vale ser preciso sobre o que isso garante: sensitive mantém o valor fora da saída do plan e dos logs. Não o mantém fora do estado. O Terraform 1.11, lá em fevereiro de 2025, trouxe a solução de verdade, os argumentos write-only: valores que passam pelo provider no apply e nunca são persistidos no estado. Até o provider do Uptimepage adotá-los, trate o próprio arquivo de estado como um segredo:

variable "admin_password" {
  type      = string
  sensitive = true
}

resource "uptimepage_target" "admin" {
  name     = "admin panel"
  interval = 120

  check = {
    type = "http"
    http = {
      url = "https://admin.example.com/"
      expected_status = {
        kind = "range"
        range = {
          min = 200
          max = 299
        }
      }
      basic_auth = {
        username = "uptime"
        password = var.admin_password
      }
    }
  }
}

A senha chega à API e fica fora do seu terminal, mas ainda acaba no estado. Use um backend que criptografe os dados em repouso e escolha com cuidado quem pode lê-lo. Quando o provider adotar os argumentos write-only, a senha deixa de tocar o estado por completo; até lá, o backend criptografado é o que de fato a protege.

Não reconstrua o que você já tem

Se você já tem monitores criados à mão, e você tem, não precisa cadastrá-los de novo. A importação guiada por configuração existe no Terraform desde a 1.5: escreva o bloco do recurso do jeito que você quer, adicione um bloco import apontando para o id do monitor existente, e o apply o adota em vez de criar uma duplicata.

import {
  to = uptimepage_target.api
  id = "the-existing-monitor-id"
}

Rode o plan e leia com olhos de águia. Uma importação limpa não mostra nenhuma mudança. Se o plan quer modificar alguma coisa, o seu HCL ainda não bate com a realidade, então corrija o código, não o monitor, até o diff ficar vazio. Depois apague o bloco import; ele já cumpriu o seu papel. Uma pegadinha da seção anterior: um segredo como aquela senha de autenticação básica não pode ser lido de volta pela API, então uma importação não vai recuperá-lo. Você mesmo o define na configuração, uma vez, e o Terraform cuida do resto.

Um fluxo de trabalho que não vai acionar você

O formato que se sustenta: estado remoto com bloqueio (para que duas pessoas não rodem o apply ao mesmo tempo e o corrompam), terraform plan rodando automaticamente em todo pull request para que quem revisa veja o diff, e o apply liberado só depois de um merge no seu branch principal. Ninguém roda apply de um notebook às 2h da manhã. A mesma disciplina que você ia querer numa migração de banco de dados, aplicada à coisa que avisa que o banco de dados caiu.

Monitores, páginas de status e canais de notificação são todos simples recursos aqui (uptimepage_status_page, uptimepage_notification_channel e companhia), então toda a face pública do seu monitoramento (qual página mostra o quê, quem é acionado em qual canal) acaba revisável no mesmo PR que as próprias verificações.

O mesmo truque funciona no outro sentido: um servidor MCP também é algo que cai, e monitorar um é um monitor que você pode declarar aqui junto com o resto.

E os mesmos monitores que você declara em código, um assistente de IA consegue ler de volta via MCP: “o que está quebrado agora, e desde quando?”, respondido em linguagem simples, a partir da mesma configuração que está no seu repositório. Declarados num pull request de um lado, consultados por um assistente do outro. Os mesmos dados, os mesmos escopos.

Entediante, em código também

Já defendemos antes que o seu monitor deveria ser a coisa mais entediante e mais confiável que você tem. A configuração faz parte disso, e vale pesá-la na hora de escolher uma ferramenta: entre as opções de código aberto e auto-hospedadas, as que guardam a configuração num arquivo que você pode commitar envelhecem melhor do que as que a escondem atrás de cliques. Também vale conferir quem de fato mantém o provider, já que muitas ferramentas dizem ter suporte a Terraform e deixam isso nas mãos de um voluntário; a comparação dos providers do Terraform para monitoramento mostra quem publica o quê. Um monitor cuja definição você consegue ler, revisar, comparar num diff e reverter é um monitor mais entediante do que um montado a partir de cliques de que ninguém se lembra, e entediante, aqui, é justamente o elogio.

Coloque a configuração no repositório. Deixe uma segunda pessoa ler o diff. O seu eu do futuro, apertando os olhos diante de um intervalo de 47 segundos daqui a dezoito meses, vai pelo menos poder rodar git blame e descobrir que foi você.