comparando monitoramento como código
O Uptime Kuma tem um provider do Terraform?
O Uptime Kuma não tem um provider próprio, nem uma API de gerenciamento documentada sobre a qual construir um. O que o Registry oferece no lugar são sete providers da comunidade apoiados numa biblioteca cliente não oficial. Um deles é bom de verdade. O que vale pesar é o que ele pede para fazer login.
A tabela abaixo é a comparação completa, sem edição. Leia primeiro, se preferir: é a mesma que enviaríamos para você.
AGPL-3.0 · um único binário · plano gratuito · sem cartão
O que sete forks da comunidade somam
| Uptime Kuma | Uptimepage | |
|---|---|---|
| provider do próprio fornecedor | nenhum | sim |
| providers no Registry | 7, todos da comunidade | um, o nosso |
| melhor opção da comunidade | breml/uptimekuma v0.4.0 | não é necessário |
| monitores como código | sim | sim |
| página de status como código | sim, da comunidade | sim |
| API de gerenciamento | nenhuma documentada | REST, documentada |
| como o Terraform se autentica | usuário e senha de admin | token com escopo |
O projeto Uptime Kuma não publica nenhum provider. O Registry retorna sete da comunidade: breml/uptimekuma, kenlee20/kuma, kenlee20/upkuapi, ehealth-co-id/uptimekuma, zahornyak/uptime-kuma-wapi, kurtmc/uptimekuma e o de TheodoreHerzfeld.
O breml/uptimekuma é o mais completo: 63 estrelas, v0.4.0 lançada em 25 de julho de 2026, commits este mês e recursos para monitores, notificações, proxies, manutenção, tags, páginas de status e incidentes da página de status.
O Uptime Kuma não documenta nenhuma API de gerenciamento, então todo provider aqui depende de um cliente obtido por engenharia reversa. O README do breml afirma que o que ele faz se limita ao que o go-uptime-kuma-client suporta.
As próprias chaves de API do Uptime Kuma expõem só métricas, então o provider recebe o nome de usuário e a senha de uma conta em vez de um token com escopo.
Verificado em 11 de agosto de 2026 no Terraform Registry e no repositório de cada provider. Os providers lançam versões com frequência, então confira antes de decidir.
O que o Registry realmente tem
O projeto Uptime Kuma não publica nada. Uma busca no Registry em agosto de 2026 retorna sete providers da comunidade: breml/uptimekuma, kenlee20/kuma, kenlee20/upkuapi, ehealth-co-id/uptimekuma, zahornyak/uptime-kuma-wapi, kurtmc/uptimekuma e o de TheodoreHerzfeld. O mais completo, com larga vantagem, é o breml/uptimekuma, com 63 estrelas, a v0.4.0 lançada em 25 de julho de 2026 e commits este mês. Ele cobre mais de trinta tipos de monitor, cerca de cem serviços de notificação, proxies, janelas de manutenção, tags e uma página de status com incidentes. Se você precisa de um, é esse.
Por que todos dependem de um cliente não oficial
O Uptime Kuma controla a interface via Socket.IO e não documenta nenhuma API de gerenciamento. As próprias chaves de API dele leem métricas e nada mais. Então todo provider aqui fala com o Kuma por meio de uma biblioteca cliente obtida por engenharia reversa, e o README do breml diz isso com todas as letras: o que o provider faz se limita ao que o go-uptime-kuma-client suporta. A cobertura, portanto, acompanha um terceiro repositório, e não as versões do Kuma, e uma atualização do Kuma pode deixar os dois para trás.
A credencial que ele pede
O bloco do provider recebe um endpoint, um nome de usuário e uma senha, ou a variável UPTIMEKUMA_PASSWORD. Esse é o seu login de administrador do Uptime Kuma. O estado do Terraform, o seu runner de CI e qualquer pessoa que consiga ler um plan recebem uma credencial que faz tudo o que a interface faz, inclusive apagar. Não há escopo para restringir nem validade em que se apoiar, porque o Kuma não tem token para emitir. Para um homelab, tudo bem. Para um pipeline compartilhado, é nisso que vale pensar antes da lista de funcionalidades.
Um monitor, e um token que só escreve monitores
provider "uptimepage" {
token = var.uptimepage_write_token # com escopo e validade
org = "acme"
}
resource "uptimepage_target" "api" {
name = "api"
interval = 60
check = {
type = "http"
http = {
url = "https://example.com/healthz"
expected_status = { kind = "exact", exact = 200 }
}
}
}Onde o Uptimepage se encaixa
Se monitoramento como código é o motivo de você estar lendo isto, o provider ser nosso, e não um fork, é o que faz a diferença. Monitores, páginas de status, componentes e canais de notificação são todos recursos, sobre a mesma API REST documentada que o painel usa, e uma execução do Terraform se autentica com um token com escopo e validade, e não com a senha de uma conta. Também há um servidor MCP sobre essa API. Grátis no plano hospedado, sem cartão, ou hospede tudo por conta própria sob AGPL.
- 01Entre com GitHub ou Google. Sem cartão, sem ligação de vendas.
- 02Cole uma URL. A primeira verificação roda antes de você terminar de ler isto.
- 03Publique a página de status, ou exporte-a para o Terraform e mantenha no Git.
api99,98%
p95 142 ms · um incidente em 45 dias
dashboard99,91%
p95 318 ms · dois dias com degradação
webhooks99,99%
p95 88 ms · nenhum incidente
RESOLVIDO14 min
Latência elevada na API do painel
14:22 resolvido, latência de volta abaixo de 300 ms
14:08 aberto automaticamente pela verificação do painel
no ar degradado fora do ar 45 dias · assinantes por e-mail e webhook