Skip to content

CONCEPT Cited by 1 source

Client-side black-box probe

Definition

A client-side black-box probe is a synthetic-monitoring primitive that issues real, protocol-shaped requests from outside the service-under-test and reports pass/fail + timing metrics. The essential contract is:

  1. Request-shaped. The probe speaks the same protocol a real client would — HTTP/1.1 GET, HTTPS handshake + request, DNS lookup, HTTP/3 over QUIC, TCP connect, ICMP echo — not an internal health-check API.
  2. Black-box. The prober has no inside knowledge of the target's implementation; it tests the observable behaviour an external client would see.
  3. Client-side. The probe runs on the client side of the network, from the perspective of where real users sit — at the edge, at a PoP, from a geographic region, from a synthetic "user" vantage point.

Contrast with in-process instrumentation — the metrics the service emits about itself. In-process instrumentation misses: the service is up but the load balancer isn't routing to it; DNS is broken; the TLS cert just expired; the CDN cache is returning stale content; QUIC is failing to establish.

Typical shape

  • Prober fleet deployed across regions / PoPs / synthetic-user vantage points.
  • Central scheduler enumerates target URLs + probe configs + fan-out policy.
  • Metrics emitted per probe: success boolean, total duration, per-phase duration (DNS / connect / TLS / request / response), protocol-specific fields (status code, body match, TLS cert expiry), vantage label.
  • Alert rules over the probe-success rate sliced by endpoint × vantage × protocol.

The canonical wiki implementation substrate is Prometheus Blackbox Exporter — which Slack describes as "a cornerstone of our monitoring" in the 2026-03-31 ingest (sources/2026-03-31-slack-from-custom-to-open-scalable-network-probing-and-http3-readiness).

Why it matters separately

Client-side black-box probes are the only metrics that catch the failure mode "the service reports healthy but users can't reach it". This is the load-bearing value prop of synthetic monitoring in general and of BBE-class tooling in particular.

Slack's 2026-03-31 post is an instructive instance: when HTTP/3 rolled out on the edge (QUIC over UDP, not TCP), the in-process HTTP servers could report healthy while real HTTP/3 clients couldn't actually connect — because no existing prober spoke QUIC. The concepts/http-3-probing-gap is specifically about client-side black-box probing missing a new transport.

  • Versus white-box / in-process metrics — black-box probes don't read the service's internal counters; they make real outside requests.
  • Versus load-balancer health checks — LB health checks are a degenerate form (usually a bespoke /healthz endpoint), not protocol-shaped. A load balancer may think a host is healthy because /healthz returns 200 even while real HTTP/3 traffic fails to that host.
  • Versus RUM (real-user monitoring) — RUM instruments actual users' browsers / apps; client-side black-box probes are synthetic — a dedicated prober fleet. RUM has coverage gaps by geography / session shape; synthetic probes are controllable and reproducible.
  • Versus distributed tracing — traces follow a request through the service graph; probes are the outer-envelope pass/fail metric that tells you whether a trace would even start.

Seen in

Last updated · 470 distilled / 1,213 read