New Starlark probe is now available — write probes in a Python-like syntax

Catch outages before
your users do.

Open-source active monitoring. Built at Google. Runs anywhere — from a Raspberry Pi to global fleets.

Get started View on GitHub ★ 700

In production at

Google, Tesla, Snowflake, Apple, DoorDash, Uber, Cloudflare, Walmart, Robinhood, Okta, Goldman Sachs, JPMorgan Chase, Hostinger, DigitalOcean, Disney+, Yahoo Japan, and more.

20M+ container pulls

Monitoring in under a minute.

1 · Install

$ curl -fsSL https://cloudprober.org/install.sh | sh

2 · Run it

$ cloudprober --config_file cloudprober.cfg

That's it. Probe results are live at localhost:9313/status, and Prometheus-format metrics at /metrics. Single binary, no agent to deploy, nothing else to stand up.

Read the getting started guide

The config, in full

probe {
  name: "cloudprober_website"
  type: HTTP
  targets {
    host_names: "cloudprober.org"
  }
  http_probe {
    protocol: HTTPS
  }
  interval: "5s"
}

Built-in Probes

Probe every layer of your stack with built-ins. HTTP, gRPC, Browser, and Starlark Script probes test the surface your users actually touch — including full headless-browser checks that drive multi-step user flows. DNS, PING, TCP, and UDP probes verify the network underneath — name resolution, packet loss, connection refused, byte-level transport issues.

All built-ins share the same scheduling, target discovery, validators, and surfacers. Mix them in one config to monitor an application end-to-end — from DNS resolution, through the TCP handshake, to the HTTP response body.

See all probe types See the Browser Probe demo

Custom Probes & Extensibility

When the built-ins don't fit, three escape hatches at increasing depth: shell out to any binary (External), run inline logic in Starlark Script, or compile a Go Extension into a private build.

Read the extensibility guide

Observability, Alerts & Status

Surfacers ship metrics where you already look: Prometheus, Datadog, CloudWatch, Google Cloud Monitoring, PostgreSQL, Pub/Sub, OpenTelemetry, plain stdout. Alert rules fire on failures, SLO breaches, or custom thresholds, delivering through PagerDuty, OpsGenie, Slack, email, or webhook.

A built-in status dashboard shows live probe state per target — worth having when the observability stack you'd normally check is itself the thing that's down.

Browse surfacers and alerts

Dynamic Templated Configs

Stop hand-writing thousands of probe definitions. Targets are discovered automatically — from Kubernetes, GCE, file-based lists, or any service you plug in — and probes are generated from templated configs.

Add a new region, a new service, or a new endpoint, and cloudprober picks it up on its next reload. Templates use Go text/template, with target metadata as variables, so a single probe block can adapt across hundreds of endpoints.

Read the config guide

One binary. Thousands of probes.

Cloudprober runs as a single Go process. Each probe is a goroutine — thousands run concurrently with sub-millisecond scheduling overhead, sharing one in-memory metrics pipeline.

Stop running an agent per region, per cluster, or per service. One cloudprober instance handles probing for an entire fleet on a single CPU core. Less ops surface. Less infrastructure to maintain. Less to break.

See the architecture

1 process

single Go binary, no agent fleet

10k+ /sec

probes per core, typical workload

<1 ms

scheduling overhead per probe

Goroutine per probe. One in-memory pipeline. No JVM, no Python, no sidecar.

Check the flow, not just the endpoint.

A 200 from your login page doesn't mean anyone can log in. This probe signs in, keeps the session cookie, loads the cart, and asserts on what came back — the actual journey, checked every interval.

It's Starlark, a Python-like language that runs inline in your config. Edit the script, reload, done: no plugin to compile, no binary to rebuild, no separate test runner to keep in sync.

Write a Starlark probe

probe {
  name: "checkout_flow"
  type: SCRIPT
  script_probe {
    starlark: """
# Multi-step probe, no rebuild required
def probe(target):
    r = http.get("https://%s/login" % target)
    assert.http_status(r, 200)

    r = http.post(
        "https://%s/login" % target,
        data = {"user": "test"},
    )
    cookies = r.cookies

    r = http.get(
        "https://%s/checkout" % target,
        cookies = cookies,
    )
    assert.contains(r.body, "Your Cart")
"""
  }
}

The whole stack, no glue.

Most synthetic monitoring setups are three or four moving parts you wire together yourself: a prober, a scrape target, an alertmanager, a dashboard. Cloudprober is one binary and one config, with all of it already connected.

Inside, they're still separate stages, each doing one job — so any of them can be swapped out or switched off without disturbing the rest. Point it at Prometheus, Grafana, or PagerDuty if you already run them — or run nothing else at all and use the built-in status page. Either way the setup grows from one VM to multi-region without swapping in a "real" tool later.

Stories from production

We overhauled Snowflake's monitoring at the network level and built our new monitoring stack on Cloudprober, which has since been adopted company-wide.

Snowflake Engineering

A Deep Dive into Envoy at Snowflake · Apr 2025

Read the post

Cloudprober does an excellent job running probes to determine the health of a system.

DoorDash Engineering

Using Active Probing to Detect Infrastructure Failures · Jan 2021

Read the post

Cloudprober only does one thing — launches and measures probes. The workflow is designed to be simple and lightweight to keep resource usage low.

Hostinger Engineering

Cloudprober Explained: The Way We Use It · Sep 2021 · ~1.8M sites from a single instance

Read the post

Also referenced in Cloudflare — Scaling with safety (May 2025)