Your monitoring currently only checks whether an external health-check endpoint returns 200 OK. What's missing, and how do black-box and white-box monitoring actually complement each other?

A simple external health check is black-box monitoring — it tells you the system responds from the outside, but nothing about why it's slow, which specific internal component is struggling, or whether it's about to fail. White-box monitoring (metrics exposed from inside the application itself — internal queue depth, per-dependency latency, resource saturation) is what actually reveals internal state and early warning signs. You need both: black-box confirms the user-facing experience is actually correct end-to-end, while white-box tells you why when it isn't, and often catches problems before they become externally visible at all.

The two approaches answer fundamentally different questions, and relying on only one leaves a real gap — this is why mature monitoring setups treat them as complementary layers, not alternatives to choose between.

Black-box monitoring observes the system from the outside, the way a real user or client would: a health check endpoint, a synthetic transaction simulating real user behavior, an uptime check from an external location — these confirm the system is actually reachable and behaving correctly from an external vantage point, which is valuable specifically because it validates the full path (network, load balancer, application, and everything in between) the way a real user actually experiences it, catching problems that internal metrics might miss (a DNS issue, a network path problem, a load balancer misconfiguration) since those live outside any single component's own internal view.

But black-box monitoring alone tells you almost nothing about why or where a problem is occurring: a failed health check tells you something's wrong, not what — is it the database, a downstream dependency, memory exhaustion, a specific code path — and a single aggregate health check can also miss partial degradation entirely (95% of users are fine, 5% are getting errors, but the health check endpoint itself happens to keep succeeding).

White-box monitoring exposes metrics from inside the application itself: request latency broken down by endpoint, error rates per dependency, internal queue depths, resource utilization, cache hit rates — this is what lets you actually diagnose a problem quickly (the golden-signals dashboard concept from the related dashboard-sprawl question is built entirely on white-box metrics) and, critically, often reveals early warning signs (a growing queue, rising memory usage, a dependency's latency creeping up) well before the problem becomes severe enough to fail an external health check at all.

The combination is what gives genuine confidence and fast diagnosis: black-box monitoring validates the actual, complete, user-facing path end-to-end (something white-box metrics alone can't fully guarantee, since an application can report itself healthy internally while still being unreachable due to an external issue); white-box monitoring gives the internal visibility needed to actually understand and quickly fix a problem once you know (or suspect) something's wrong, and often surfaces problems proactively before they'd ever show up as a black-box failure.

A single external health check specifically misses: partial/percentage-based degradation, internal component-level failures that don't (yet) affect the aggregate health check response, and any leading indicator that would give advance warning rather than only alerting once the failure is already externally visible.

• Black-box monitoring validates the system from the outside, the way a real user experiences it — essential for confirming the full end-to-end path actually works, but tells you almost nothing about why a failure is happening.
• White-box monitoring exposes internal application state, enabling fast diagnosis and often catching problems before they're severe enough to be externally visible at all.
• A single aggregate external health check can miss partial degradation entirely, since it only reports binary success/failure for one specific checked path.
• Mature monitoring uses both layers together — they answer different, complementary questions, not competing approaches to choose between.

• Google SRE Book: Monitoring Distributed Systems
• Prometheus Docs: Blackbox Exporter