It is 9am and the incident channel is quiet. Every infrastructure dashboard is green: CPU nominal, memory fine, no pod restarts, latency at the load balancer perfectly flat. And yet, for the last hour, every new signup has failed at the final step because a downstream provider quietly started rejecting the account-creation call. This scenario, healthy infrastructure and a broken product, is the entire reason the distinction between product health monitoring vs. infrastructure monitoring matters. They answer different questions, and confusing them leaves a gap that outages love to live in.
Both are essential and neither replaces the other. The goal of this post is to draw the line clearly, show where each one is blind, and give you a simple rule for deciding what belongs in which system. If the category "product health monitoring" is new to you, the primer is what is product health monitoring.
What infrastructure monitoring watches
Infrastructure monitoring watches the machines and platform your software runs on. It is the domain of Prometheus, Grafana, CloudWatch, and the infrastructure side of Datadog. Its signals are the classic ones:
- CPU, memory, and disk utilization
- Network throughput, connection counts, and packet loss
- Host and container liveness, restarts, and scheduling
- Queue depths, database connection pools, and cache hit rates
- Kubernetes pod status, node pressure, and autoscaling events
Infrastructure monitoring answers the question: are the machines healthy? It is indispensable, because you cannot run a reliable product on unreliable infrastructure, and it is good at what it does. But its entire worldview is the substrate. It has no concept of what your product is supposed to do.
What product health monitoring watches
Product health monitoring watches the outcomes your customers pay for. Its signals are not utilization metrics but correctness and behavior: is the checkout flow completing, is the API returning valid data, are integrations authenticated, is the product configured and compliant. It watches the five dimensions of product health (availability, performance, security, configuration, and compliance) from the perspective of the user, not the host.
Product health monitoring answers a different question: is the product doing its job? It sits above infrastructure and application performance monitoring, at the layer where business logic and user-facing correctness live. Where infrastructure monitoring sees a 200 response and a healthy pod, product health monitoring asks whether that 200 contained the right answer.
The gap: green infrastructure, broken product
The reason you cannot substitute one for the other is that a whole class of failures never touches an infrastructure metric. Consider some entirely realistic examples:
- An expired API credential to a payment provider makes every transaction fail, while CPU, memory, and latency stay perfectly flat.
- A feature flag flipped in a third-party dashboard silently disables a core capability. No deploy, no infrastructure event, no alarm.
- A schema migration leaves a background job writing to the wrong table. The job runs, the host is healthy, the data is quietly wrong.
- A downstream API starts returning HTTP 200 with an error body instead of a 500. Every latency and error-rate metric looks pristine; the product is broken.
- A certificate on an internal service expires. Infrastructure is fine; the integration that depends on it fails closed.
The dangerous pattern: in every one of these, the infrastructure dashboards stay green the entire time. A team that treats "infrastructure is healthy" as "the product is healthy" will not learn about any of these from monitoring. They will learn about it from a customer.
A side-by-side comparison
The two disciplines line up cleanly once you see them next to each other:
| Dimension | Infrastructure monitoring | Product health monitoring |
|---|---|---|
| Question it answers | Are the machines healthy? | Is the product doing its job? |
| Primary signals | CPU, memory, disk, network, pods | Availability, performance, security, configuration, compliance |
| Point of view | The host / platform | The customer / capability |
| Typical tools | Prometheus, CloudWatch, Datadog infra | Health rules, synthetic + business-logic checks |
| Blind to | Business-logic and correctness failures | Low-level resource exhaustion |
| Owned by | Platform / SRE | Product owners + platform |
Where APM fits in between
Application performance monitoring (APM), which covers distributed traces, spans, latency percentiles, and code-level error rates, sits between the two. It is closer to the product than infrastructure monitoring, because it understands requests and code paths, but it still stops short of semantic correctness. APM will tell you a request took 90ms and returned a 200. It will not tell you the 200 was wrong. The trio is a stack: infrastructure monitoring watches the substrate, APM watches how the code executes, and product health monitoring watches whether the outcome is correct. Mature teams run all three because each is blind to what the others see.
Why you need both: they are complementary, not competitive
None of this is an argument against infrastructure monitoring. It is an argument against stopping at infrastructure monitoring. The two are complementary in a specific, useful way. Infrastructure monitoring is your best early warning for capacity and platform problems: a memory leak, a disk filling, a node under pressure. Product health monitoring is your best early warning for correctness and integration problems: an expired credential, a config drift, a broken business rule. Each catches failures the other structurally cannot.
In practice they also help each other during incidents. When product health monitoring flags that checkout is unhealthy, infrastructure and APM dashboards are where you go to find out why. Product health tells you that the product is broken and how; the lower layers help you localize the cause.
How to decide what belongs where
A simple rule resolves almost every "which system should watch this?" question:
If the signal is about the resources your software consumes, it belongs in infrastructure monitoring. If the signal is about whether a customer gets the right outcome, it belongs in product health monitoring.
Applied:
- "Is the database CPU above 80%?" → infrastructure.
- "Did the last hourly export write rows for every tenant?" → product health.
- "Is the pod count matching the desired replica count?" → infrastructure.
- "Is the payment credential valid and not expiring this week?" → product health.
- "Is p99 request latency within SLO?" → APM, surfaced as a product-health performance signal.
Signs your team has a product health monitoring gap
Most teams do not decide to skip product health monitoring; they simply never notice the gap, because infrastructure dashboards are so reassuringly green. A few symptoms reliably indicate that the gap is there:
- Customers report outages before you detect them. If your fastest detection channel is the support inbox, your monitoring is watching the wrong layer.
- Incident post-mortems keep concluding "infrastructure was fine." When the root cause is repeatedly a credential, a config change, or a business-logic bug that no dashboard caught, that is a product-health gap by definition.
- Nobody can answer "is feature X working right now?" without manually clicking through the product. If the only way to know is to try it yourself, it is not being monitored.
- Integrations fail silently. Third-party dependencies break in ways that never touch your CPU graphs, and you find out days later.
- Your dashboards measure the system, not the customer. If you cannot point to a single view that says "the things customers pay for are working," you are monitoring the substrate and hoping the product follows.
None of these mean your infrastructure monitoring is bad. It usually means it is working perfectly at the job it has, which is not this one. The fix is not to tune the infrastructure alerts harder. It is to add the layer that watches outcomes.
Where Sentrock fits
Sentrock is the product health layer that sits above your infrastructure and APM tooling. You keep Prometheus, CloudWatch, or Datadog for the substrate, and Sentrock does not replace them. What it adds is the missing top layer: a product health monitoring platform where you define health rules for user-facing outcomes across all five dimensions. You run them on a schedule and get alerted when the product degrades even while the infrastructure stays green. It is built precisely for the failures that never trip an infrastructure alarm. You can learn more about how Sentrock works and see where it slots into a stack you already have.
Takeaways
- Infrastructure monitoring answers "are the machines healthy?" Product health monitoring answers "is the product doing its job?" They are different questions.
- A large class of failures (expired credentials, config drift, broken business logic, wrong-but-200 responses) is invisible to infrastructure monitoring.
- Run both, plus APM. Each is blind to what the others catch.
- Resources → infrastructure. Customer outcomes → product health. That rule sorts almost everything.
The next step up from understanding the distinction is building the practice around it. The teams that reliably ship dependable products are not the ones with the most infrastructure dashboards. They are the ones who deliberately monitor customer outcomes as a separate, first-class concern, and treat "infrastructure is green" as necessary but never sufficient. For how to build that practice end to end, read SaaS reliability monitoring best practices, or add a product health layer to the monitoring you already run.
Written by the Sentrock Team
Sentrock is a product health monitoring platform for SaaS teams. Define health rules across availability, performance, security, configuration, and compliance. Know the moment something degrades, before your customers do.
Start monitoring your products →