Your infrastructure dashboard is a wall of green. CPU is fine, memory is fine, every host is responding to its health-check ping. Then a customer emails: checkout has been failing for forty minutes. Orders are silently returning a 200 OK with an empty cart. Nothing is "down," and that is exactly the problem. The gap between "the servers are up" and "the product works" is what product health monitoring exists to close.
Product health monitoring is the practice of continuously verifying that a product delivers the outcomes customers depend on: correct behavior, acceptable performance, valid configuration, and a sound security posture. It does not just confirm that the machines it runs on are alive. For SaaS teams, this is the difference between finding out about a problem from your monitoring and finding out about it from an angry support ticket.
What product health monitoring actually means
Traditional monitoring answers an infrastructure question: is the system running? Product health monitoring answers a business question: is the product doing its job? Those are not the same question, and the second one is the one your customers actually care about.
A useful way to think about it: infrastructure monitoring watches the layer you operate, while product health monitoring watches the outcomes you promise. A payment API can be responding in 80 milliseconds with a perfect 200 status code and still be rejecting every real transaction because a downstream credential expired. The host is healthy. The product is not.
The practice generally has three moving parts. Health rules are explicit, codified definitions of what "healthy" means for a specific product or capability, evaluated on a schedule. Status states give you a graded model (healthy, degraded, unhealthy) instead of a binary up/down, so a service that is slow but working reads differently from one that is broken. We cover that in defining healthy, degraded, and unhealthy service states. Alerting and history route a status change to the people who own that product and keep a durable record, so you can see patterns before they become incidents.
The five signals of product health
"Health" is not one number. For a SaaS product, it is a composite of several independent signals, each of which can degrade on its own. A mature product health monitoring practice tracks all five:
- Availability. Can customers reach and use the product? This is the closest to classic uptime, but scoped to user-facing capabilities, not hosts.
- Performance. Is it fast enough to be usable? A product that technically responds but takes eight seconds per page is degraded, not healthy.
- Security. Is the security posture intact? Expiring certificates, lapsed credentials, and misconfigured access controls are health problems long before they become breaches.
- Configuration. Is the product configured the way it is supposed to be? Drift (a feature flag flipped, a limit misset, an environment variable missing) silently breaks products that are otherwise "up."
- Compliance. Does the product still meet the policy and regulatory requirements it is contractually held to? Retention windows, data residency, and audit settings all belong here.
Why five and not one? Because they fail independently and demand different responses. A performance dip might warrant a quiet ticket; a compliance violation might warrant paging a CISO. Collapsing them into a single "up/down" light throws away the information you need to respond correctly.
How product health monitoring differs from infrastructure monitoring and APM
Three categories get conflated constantly, so it helps to draw sharp lines. They are complementary, not competitive, and most serious teams run all three. Infrastructure monitoring (Prometheus, CloudWatch, Datadog infrastructure) watches the substrate: CPU, memory, disk, network, and container restarts. It answers whether the machines are healthy. Application performance monitoring, or APM (traces, spans, latency percentiles, error rates), watches how your code executes and answers whether the application is fast and error-free at the code level. Product health monitoring watches user-facing outcomes and product-specific correctness, and answers whether the product is doing what customers pay for.
APM will tell you a request returned a 200 in 90ms. It will not tell you the 200 contained the wrong data because a business rule broke. That last mile (semantic correctness, product-specific logic, the five signals above) is the product health layer. We go deeper on this distinction in product health monitoring vs. infrastructure monitoring.
Reactive vs. proactive monitoring
Most teams start reactive without meaning to. The pattern is familiar: something breaks, a customer notices, a ticket comes in, an engineer scrambles, the fire gets put out, and everyone moves on until the next one. The monitoring, in effect, is your customers.
Proactive monitoring inverts the order of discovery. You define, ahead of time and in code, what "working" means for each product capability, and the system checks it continuously. The goal is simple to state and hard to achieve: your team should learn about every meaningful product problem before a customer does.
The maturity test for a monitoring practice is not "how fast do we respond to incidents?" It is "how often does a customer tell us about an incident we didn't already know about?"
Moving from reactive to proactive is mostly a matter of codifying tacit knowledge. The senior engineer who "just knows" the export job is wedged when the queue depth climbs is holding a health rule in their head. Product health monitoring is the discipline of writing that rule down so the system can watch for it at 3am when that engineer is asleep.
A concrete example: monitoring a checkout flow
Abstractions only get you so far, so make it concrete. Imagine a SaaS product with a checkout flow that creates a subscription through a third-party payment provider. What does product health monitoring look like here, signal by signal?
- Availability: a synthetic check creates a test subscription end to end every five minutes and asserts it reaches the "active" state, not just that the checkout page returns a 200.
- Performance: the same check records how long the create-subscription round trip takes and flags degraded when the 95th percentile crosses, say, three seconds.
- Security: a rule verifies that the payment provider API credential is present, valid, and not within 30 days of expiry, because an expired key turns every checkout into a silent failure.
- Configuration: a rule asserts the active price IDs and webhook endpoints match what the product expects, catching the classic "someone changed a setting in the provider dashboard" outage.
- Compliance: a rule confirms that transaction records are being written to the retention-compliant store and that PII fields are masked as policy requires.
Notice what infrastructure monitoring sees in this scenario: nothing wrong. The web servers are healthy, the database is accepting connections, latency at the host level is nominal. Every one of the five product-health failures above can happen while the infrastructure stays green. That is precisely why the product layer needs its own monitoring. The checkout example generalizes: any capability a customer pays for can be decomposed into these signals and watched continuously.
What it costs to fly blind
Teams that lack product health monitoring pay for it in predictable ways:
- Customer-reported outages. Your fastest detection channel becomes your support inbox, the worst possible place to learn your product is broken.
- Trust erosion. Every "actually, it's been broken since this morning" costs credibility that compounds. B2B buyers remember reliability.
- Reactive firefighting. Engineering time gets consumed by unplanned incident response instead of the roadmap, and the team burns out on pages that could have been quiet tickets.
- Invisible degradations. The failures that never trip an infrastructure alarm, like a slow leak in a background job or a silently expired integration, run for days because nothing was watching the right signal.
Who owns product health monitoring?
One reason product health falls through the cracks is that no single team obviously owns it. Infrastructure monitoring belongs to platform or SRE. APM belongs to the application teams. But product health sits across all of them, and the signals (availability, performance, security, configuration, compliance) map to different owners.
The workable model is federated: each product or capability has a named owner who defines and maintains its health rules, while a platform team provides the shared monitoring system and the conventions. This mirrors how incident response already works in most mature organizations: the person who owns the code owns the pager. Product health monitoring extends that ownership left, to before the incident. When you assign owners explicitly and route each status change to the right one, "who should look at this?" stops being a question asked in the middle of an outage. The tooling should make that routing automatic rather than tribal knowledge.
How Sentrock approaches product health monitoring
Sentrock is a product health monitoring platform built around exactly this model. You connect the products you run, define health rules across the five signals (availability, performance, security, configuration, and compliance) and set the interval, thresholds, and status logic that match how each product actually behaves. Sentrock evaluates those rules on schedule and rolls the results up into a single view of healthy, degraded, and unhealthy across your entire estate.
Where the built-in checks can't express something product-specific, you can write your own logic as a custom Python health rule that runs in an isolated sandbox. That is the subject of writing custom health checks in Python. When a rule degrades or fails, the owners of that product are alerted immediately, and the full status history is there to diagnose the pattern rather than just the symptom. The point is not more dashboards; it is knowing about product problems before your customers do.
Getting started with product health monitoring
You do not need a platform to begin. You need a practice. A pragmatic first pass:
- Pick your three most important products or capabilities. Start where an outage hurts most.
- Write down what "healthy" means for each in plain language, across the five signals. This is the hardest and most valuable step.
- Turn those definitions into checks that run on a schedule, not on demand.
- Route status changes to the owner, and keep the history.
- Expand from there. Every incident that surprises you is a missing health rule.
Tip: The best source of new health rules is your incident history. Every post-mortem that ends with "we should have caught this sooner" is describing a rule you can now codify so the system catches it next time.
Product health monitoring is a shift in what you consider your job done: not "the servers are up," but "the product works, and we'd be the first to know if it didn't." If you want to see what that looks like in practice, the deeper mechanics live in our guide to SaaS reliability monitoring best practices. Or you can start monitoring your own products and define your first health rule in minutes.
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 →