Blog
How we measure: reachability vs self-report
How StackWitness measures dependency hosts: multi-region reachability probes plus vendor status feeds. What reachable means, and what we never claim.
StackWitness is built around one discipline: separate what we measured from what a vendor said about itself.
Two inputs
1. Our probe. From multiple Cloudflare edge regions we send an identifying GET to the public service host (honest User-Agent, documented at /bot). We classify reachability from status and latency. We discard bodies. We do not authenticate. We do not perform side-effecting requests.
2. Vendor status feed. Separately, we read the vendor's public status JSON when one exists. That column is labeled as their self-report.
What "reachable" means
Reachable means the host answered our probe in a way that counts as up under our rules. It does not mean every API method works, every region is fine for every customer, or that the vendor met a contractual SLA. We use reachable language on purpose so calm green never pretends to be a full product audit.
What we never claim
- We do not issue a compliance verdict
- We do not guarantee vendor uptime
- We do not invent operational green when we did not measure
- We do not treat "vendor reports outage" as something we need to contradict from a handshake alone
Why the comparison exists
Teams already have APMs for their own code. What they lack is an outside clock on the dependencies those APMs cannot see clearly. Reachability plus self-report is a narrow, honest instrument. It will not replace deep synthetic transactions for every product surface. It will answer the 3am question faster than refreshing a status page that has not moved.
If you want the same engine on your own endpoints and customer-facing status page, that is the paid product. The public truth pages stay free to read so the method is inspectable.