comparing self-hosted
Blackbox exporter vs Uptime Kuma: a part or a product?
These are not two versions of the same thing. Uptime Kuma is a product you install and use. The Prometheus Blackbox exporter is one component of a monitoring system you assemble yourself, and on its own it does almost nothing.
the facts, side by side
| Blackbox exporter | Uptime Kuma | Uptimepage | |
|---|---|---|---|
| license | Apache-2.0 | MIT | AGPL-3.0 |
| works on its own | no, it is a component | yes | yes |
| what you operate | exporter + Prometheus + Alertmanager + Grafana | one container | hosted, or one binary |
| probe types | http · tcp · dns · icmp · grpc · unix | 31 types | HTTP · TCP · DNS · TLS · ping · domain |
| who schedules the check | Prometheus, default 60s | built in, down to 1s | built in, from 60s |
| alerting | PromQL rules you write + Alertmanager | 94 integrations | 14 native integrations |
| certificate expiry | a metric, alert it yourself | a check with an alert | a check with an alert |
| dashboard | debug page only | built in | built in |
| status page | none | basic, RSS only | branded, with subscribers |
| reaches private targets | yes | yes | yes, with your own agent |
| multi-region probes | deploy N exporters yourself | via Globalping add-on | multi-region, run your own |
| teams & roles | one basic-auth password | single login | orgs + roles |
| community (GitHub stars) | ~5.8k | ~89k | young |
The Blackbox exporter has no scheduler. A probe runs only when Prometheus requests it, so check frequency is Prometheus's scrape interval, which defaults to one minute.
Certificate expiry is exposed as the probe_ssl_earliest_cert_expiry metric rather than asserted by the probe; turning it into an alert is a PromQL rule you write.
The exporter serves a small in-memory debug page listing recent probes, not a status page. Its history is lost on restart.
Probers listed are those in the current release, v0.28.0. A websocket prober exists on master but is not in any released version.
Verified July 2026 against Blackbox exporter v0.28.0 and Uptime Kuma 2.4.0. Both projects move quickly, so check their current source before you decide.
The exporter does not monitor anything by itself
This is the part people discover late. The Blackbox exporter has no scheduler: it exposes a probe endpoint, and a probe runs only when something asks for it. That something is Prometheus, which decides how often to ask, stores the result and evaluates your alerting rules. Alertmanager then does the actual notifying, and Grafana draws the dashboard. So a working uptime setup is four moving parts you install, configure, secure, upgrade and keep alive, not one. Check frequency is not even an exporter setting; it is Prometheus's scrape interval, which defaults to one minute.
Where the exporter genuinely wins
Precision, and fitting an estate you already run. It probes over HTTP, TCP, DNS, ICMP, gRPC and unix sockets, and it asserts on things most tools cannot express: regexes against DNS answer sections, TCP send-and-expect scripts with STARTTLS upgrades, byte-exact matches, CEL expressions over JSON bodies, response-header regexes, even pinning a maximum TLS version to prove an insecure one is not offered. If you already run Prometheus, probe data lands in the same store as your application metrics at no marginal cost, and it reaches things a hosted checker structurally cannot: internal VIPs, private DNS resolvers, sockets on the host.
Where Uptime Kuma wins
It is finished. One container, five minutes, and you have 31 monitor types, 94 notification integrations, a dashboard, a status page and intervals down to one second. Someone who is not an engineer can add a check. With the exporter, adding a check is a YAML edit plus a Prometheus relabel rule plus a config reload, and turning certificate expiry into an alert means writing PromQL against a gauge yourself, because expiry is exposed as a metric rather than asserted by the probe.
The blind spot they share
Neither watches itself. If your Prometheus is down, nothing probes and nobody is told. If your single Kuma container is on the host that just died, the same. Self-hosted monitoring that lives next to the thing it monitors will always miss the outage that takes both down, which is the whole argument for a probe that runs somewhere else.
Where Uptimepage fits
Uptimepage is a finished product like Kuma, but it checks from outside your infrastructure by default, from multiple regions, and you can still run your own probe agent inside the network for the private targets that only the exporter could reach before. On top of the checks: a branded status page with confirmed email and webhook subscribers, incidents opened automatically, organizations with roles, and a Terraform provider, REST API and MCP server, so the config stays in Git the way a Prometheus setup does. Hosted free with no card, or self-host under AGPL.