Why Most Monitoring Strategies Fail and How the CAR Framework Fixes Them

Unverified observability and constantly on‑call teams inevitably encounter response interruptions, which feel like searching for a needle in the sea while blindfolded; the author has stabilized chaotic teams before.

Undetected degradations cause user pain.

Endless, tsunami‑like noisy alerts.

24‑hour on‑call pressure is unsustainable.

The article targets exhausted engineers and managers who want to add a mature technology to their toolbox, because who doesn’t want an efficient team?

Four Reasons That Affect a Team’s Permanent Response

Disconnect : A gap exists between the organization’s perception of user experience and the actual experience. Typical symptoms include:

Monitoring reports “healthy” while user complaints keep coming.

Lack of proactive fault detection; issues are only seen after users report them.

Engineers trying to explain how a page affects users.

An engineer accidentally discovers a broken feature.

Distrust : Frequent false alerts erode confidence in the monitoring system, leading engineers to ignore alerts until a massive outage occurs.

Disorganization : Without clear guidance, teams rely on ad‑hoc monitoring frameworks, untested tools, and temporary fixes such as simply rebooting a machine.

Disrepair : Tools, systems, and alerts become outdated or poorly maintained, causing failures for various reasons.

How Monitoring Strategies Disappoint Users

The goal of monitoring is to ensure a good user experience by catching problems early or mitigating those that slip through. Most solutions fail not because the tools are lacking, but because they are misused and the core problem is misunderstood.

Often the number of fire‑fighting engineers matches the number of observability tools. If the issue were purely tooling, using Prometheus, Nagios, Geneva, Kusto, etc., would solve it.

Users only care when a fault causes irreversible damage; occasional crashes or freezes are tolerable, but lost work or persistent issues are not.

User‑centric observability metrics must answer: Are users satisfied? Answering this shapes the observability stack and influences operational practices.

Elements that make users satisfied include:

Product team focus on performance, reliability, durability (see “No Surprises”).

Platform team understanding not only direct service users but also partner‑team users.

Metrics that often indicate dissatisfaction:

Reliability – failures due to internal errors.

Latency – operations taking longer than expected.

Availability – internal errors exposed to users.

Durability – data loss in critical systems.

Service outage – system unavailable when a request is made.

Why Good Observability Metrics Matter

User‑centric metrics have two goals:

Guide objectives: they act as a lighthouse for improving services, helping prioritize work, track fixes, and focus on high‑leverage interventions.

Proactive alerts: highly accurate alerts provide early warnings of regressions, ensuring any sudden drop in health is directly tied to real user impact.

Below is a battle‑tested, validated strategy.

CAR Framework

The Three Entities: Customer, Application, Resource

CAR stands for Customer, Application, and Resource. By establishing interactions among these three entities, it offers a solution to monitoring disconnects.

It works like a testing pyramid, ensuring overlapping monitoring coverage and comprehensive test coverage.

Resources (e.g., VMs, caches) form the foundation for applications, which in turn are built to satisfy user needs.

Customer: wants to accomplish tasks (write a document, watch YouTube); satisfaction depends on the application working as expected.

Application: solves problems but may crash or error, especially if resources are insufficient.

Resource: provides the necessary host (CPU, memory, I/O) for the application to run smoothly.

Most strategies assume a healthy application and resources guarantee a great user experience, but this assumption often fails.

Results of Using CAR

Applying the CAR strategy across teams yields several outcomes:

Blind‑spot identification: detects previously unnoticed interruptions and reveals long‑standing hidden defects, prompting architectural fixes.

Workload reduction: incident volume drops dramatically, mainly due to eliminated noisy alerts.

Trust restoration: alerts now indicate real user problems, motivating engineers to find root causes.

Proactive execution: fewer incidents and less time spent exposing architectural flaws allow teams to shift from reactive fire‑fighting to focused problem solving.

Everyone benefits: users experience fewer interruptions, and engineers receive fewer frantic calls.

Conclusion

Most typical monitoring strategies “see the trees but not the forest” – they focus on resource or application health while ignoring the most critical question: are users satisfied?

Tie your monitoring strategy directly to user satisfaction; if users cannot use your application, achieving “nine nines” uptime is meaningless.