Black-box monitoring tests the service from outside, the way a user would, and is well suited to paging. White-box monitoring reads internal metrics and logs, and is essential for debugging and for spotting trouble before users feel it. Most teams need both, with black-box checks driving the pages.
The definitions
The Google SRE book describes the two this way. Black-box monitoring tests externally visible behavior and detects active, symptom-level problems. White-box monitoring depends on internals such as metrics, logs and handler statistics.
What black-box does well
- It only alerts when a problem is happening and affecting users, so false alarms are rare.
- It tests the whole path, including DNS, certificates, load balancers and the application.
- It is simple to explain: the login journey failed from two locations.
The SRE book notes that it suits paging because it fires on ongoing problems.
Where black-box falls short
- It is weak at catching imminent failures. A disk filling quietly will look fine until the moment it does not.
- It sees a failure but not the reason.
- It checks only the journeys you scripted.
What white-box does well
- It can detect imminent problems, such as queue growth or a rising retry rate.
- It can see failures that retries hide from users. A service may succeed on the third attempt while burning capacity.
- It is how you debug. When the page fires, white-box data tells you where to look.
Where white-box falls short
- It can alert on things users never notice.
- It depends on your instrumentation, so gaps in code mean gaps in visibility.
- A dead service may emit no metrics at all, which can look like quiet instead of broken.
A workable combination
- Synthetic checks for your key journeys, such as sign in, search and checkout, from more than one location. Page when two locations fail in a row.
- Error ratio and latency alerts built from real traffic metrics. Page on burn rate.
- White-box capacity and saturation signals as tickets and dashboards.
- A check that the monitoring itself is alive, such as a heartbeat.
Pitfalls for synthetic checks
Keep test accounts separate from real data and never reuse production credentials in scripts. Store them in your secrets system, rotate them, and log their use so they are flagged, not excluded, in your security logs. OWASP advises flagging known internal actors instead of leaving them out.
Quick check
Is a ping check enough?
Rarely. A server can answer a ping while the application is broken. Test a real user journey where you can.
How many locations should a synthetic check use?
More than one, so a fault in the checker's own network does not page you. Pick a number that fits your budget and risk.
Sources
Last reviewed: 19 October 2026.
