Cloudprober and the case for probing your systems from the outside

The monitoring model is a question, not a metric

Cloudprober is described as active monitoring software to detect failures before your customers do, and the mechanism is probes, also called synthetic monitoring.

The distinction from passive monitoring is the whole idea. A passive system watches the metrics your application already emits and alerts when a number crosses a threshold. A prober asks a question on a schedule: is this HTTP endpoint returning what it should, is this TCP port accepting connections, does this DNS name resolve, does this gRPC service answer. The signal is one your own telemetry cannot produce, because your telemetry only exists for requests that arrived.

The framing in the project documentation is that Cloudprober adds active probes to your monitoring to check that your systems, whether homelabs, microservices, APIs, websites or cloud-to-on-prem connections, run smoothly. The scope spans both ends of a network, which matters for the kind of failure it is designed to catch: a path that is broken for your customers but fine for the service itself.

The project also has documentation aimed at people who are not sure this is for them, with articles on why you need probers and on what you should probe, and a comparison against the Prometheus Blackbox Exporter. The latter is the closest alternative and the project publishes a direct comparison, which is the fair place to start if you already run that.

The homepage is cloudprober.org, the licence is Apache-2.0, and the primary language is Go.

Six built-in probe types plus two extension routes

The probe list is the concrete feature set, and it is broader than the blackbox exporter style of monitoring.

Built-in probes cover HTTP, PING, TCP, DNS, gRPC and UDP. On top of those there are custom in-process scripts written in Starlark, and external probes.

The two extension routes solve different problems and the distinction is worth making. A Starlark script runs inside the Cloudprober process, so it can do a check that no built-in probe covers without leaving the binary. An external probe is a separate program that Cloudprober drives, which is the route for a check that needs its own dependencies or its own process.

The examples directory in the repository is organised to match, with a starlark directory and an external directory among others, plus external_grpc, grpc, validators, surfacers, targets, templates, tracing, tls, oauth, sql, schedule, percentiles, include, dual_stack, additional_label and extensions.

That directory listing tells you what the project's extension points really are. Validators and surfacers are separate from probes, so you can write a custom validator and reuse it across probe types, and surfacers are how results leave the system.

The feature list also mentions custom metrics with flexible latency histograms and configurable labels, which is the detail that decides whether the data is usable in Prometheus.

Auto-discovery is the feature that removes redeployments

The second item in the feature list is auto-discover targets, described as monitoring Kubernetes, GCP or file-based resources without constant redeployment.

This is the operational argument for Cloudprober over a static target list, and it is the reason a lot of monitoring configuration is painful in the first place. If you have to add a new host to your monitoring by editing a config file and restarting the agent, then every deploy of new infrastructure becomes a monitoring change, and monitoring changes get deferred.

The repository layout shows how the target machinery is separated out. There is a top-level targets/ directory alongside probes/, surfacers/, validators/, config/, internal/, common/, metrics/, state/, web/, pkg/, cmd/, logger/, contrib/, docs/, tools/ and examples/.

A surfacer in this design is the destination for probe results, and there is a surfacers/ directory, plus a surfacers example directory. The feature list names the destinations it supports out of the box: Prometheus, Grafana, Datadog, AWS CloudWatch, PostgreSQL and Google Cloud Monitoring.

The dependency list confirms the range. The go.mod file pulls in the Prometheus client model, the AWS SDK for CloudWatch, the Google Cloud libraries for logging, pubsub and BigQuery, pgx for PostgreSQL, miekg/dns for the DNS probe, OpenTelemetry SDK and exporters, and a Starlark interpreter at go.starlark.net.

Alerting is a destination, not a separate system

The fourth feature is easy alerts, staying informed via email, Slack, PagerDuty, OpsGenie or any other HTTP based system.

The framing here matters. Alerting in Cloudprober is not a separate subsystem you configure with its own rules language, it is a destination for probe results, in the same way that a metrics backend is a destination. That is a different architecture from a monitoring system where you write a rule against a metric and the rule engine decides to page you.

The practical consequence is that a probe failure is an event, not a threshold crossing. If your HTTP probe expects a 200 and gets a 503, that is a discrete result that can be sent somewhere immediately, without waiting for a time series to accumulate enough samples for a rate to look wrong. For a synthetic check whose whole purpose is to catch a specific condition, that is the right shape.

The other reason this is convenient is the last point in the feature list, extensibility: easily adding new probe types, targets or monitoring systems. If your organisation pages through a webhook, that integration is a surfacer, not a special case.

The repository also has a state/ directory at the top level, which is where a monitor that needs to remember things between runs would keep them, and a web/ directory, which is presumably the interface for a running agent.

One static binary, and the Docker image that wraps it

The deployment story is the part that makes Cloudprober easy to drop into an existing setup.

It is written in Go, compiles to a single binary, and runs efficiently as a standalone app or as a Docker container. The Makefile confirms the build layout, with the binary produced from ./cmd/cloudprober/. and the build targets listing the platforms:

LINUX_PLATFORMS := linux-amd64 linux-arm64 linux-armv7
BINARIES := $(addprefix cloudprober-, $(LINUX_PLATFORMS) macos-amd64 macos-arm64 windows-amd64)

The linker flags strip the binary and link it statically, which is what makes it practical to copy the same file into a minimal container or a scratch image:

LDFLAGS ?= "$(VAR_LD_FLAGS) -s -w -extldflags -static"

The Dockerfile expects the multi-platform cloudprober binaries to exist in the same directory, and its comment shows the intended run command, which mounts a config file into the container:

#   docker run --net host -v $PWD/cloudprober.cfg:/etc/cloudprober.cfg \
#                         cloudprober/cloudprober

The image is built on alpine, with a first stage that selects the right architecture binary and a second stage that copies just the binary in. There are also Dockerfile.dev, Dockerfile.fips and Dockerfile.pw variants, and the Makefile carries separate tag sets for the FIPS and PW images, so the project ships distinct builds for hardened and FIPS-required environments.

Adoption by large operators, and the project that grew out of Google

The project documentation includes a section headed trusted by leading organizations, with logos for Google, Cloudflare, Robinhood, Apple, Snowflake, Uber, DoorDash, Tesla, Walmart, Okta, and a longer list including Hostinger, DigitalOcean, Disney Plus, Yahoo Japan, Crusoe and a bank. Logos are not evidence on their own, but the accompanying links to write-ups are.

The project links to how DoorDash and Hostinger use Cloudprober, with a DoorDash engineering blog post on active infrastructure monitoring and a Hostinger blog explaining the way they use it. Those are the two accounts worth reading if you want to know what a serious deployment looks like, and they are the kind of thing that answers the question of what this tool is actually for.

The origin story is also documented, and there is a note at the end of the project description saying that active development moved from the old google/cloudprober location. That is the shape of a project that began inside a large company and was moved out to its own organisation, and it explains the reference to Google Cloud Monitoring in the integration list alongside Prometheus, Grafana, Datadog, CloudWatch and PostgreSQL.

The release record shows steady work. The listed releases are v0.14.5 on 2026-08-26, described as mostly a housekeeping release with some DNS probe changes and a couple of fixes, and v0.14.6 on 2026-09-28, with a pre-release binaries tag from 2023-05-16. The last push to the repository was on 2026-10-05.

Where a prober is the wrong tool

Three cases come to mind where this approach does not fit.

The first is when you need to know what real users experienced. A prober measures a synthetic request from a known location on a schedule. It tells you that the endpoint is up for the prober, which is not the same as telling you what happened to the requests from your users. For that you need real user telemetry, which is what your APM and your logs are for.

The second is placement, and it is the mistake people make with these tools. A prober running inside the same network as the target is a poor detector of the failure that matters most, which is a broken path from the outside. If your probers sit in the cluster that cannot reach the internet, they will report everything healthy while your customers see nothing. You want the vantage point to be somewhere the failure is visible.

The third is the cost of the configuration itself. Cloudprober is a tool that asks you to enumerate what matters and how to check it, and that work does not scale down to a small deployment. A team with one service and a hosting provider's status page should use the status page.

The features that address the scaling problem are auto-discovery and the export targets, not a way to avoid deciding what to check.

Editorial conclusion

Cloudprober suits a team that wants a single agent to check reachability and latency of internal and external endpoints from several vantage points and land the results in the monitoring stack it already runs, since the export targets are built in and the binary is a single static file. It does not suit a team whose monitoring is entirely metric and log based, because a prober measures a synthetic request rather than your real traffic, and it does not suit someone who wants a hosted service, since this is a binary you run yourself. Before you deploy it, decide where the probers run, because a probe running inside the same network as the target cannot tell you that the path from outside is broken, and note that the last push was on 2026-10-05 with v0.14.6 published on 2026-09-28.

Frequently asked questions

Official sources

1. cloudprober/cloudprober on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases