Symptom

Origin & evolution

The symptom-versus-cause distinction was borrowed from medicine, where a symptom is what the patient reports and the cause is what the clinician must infer. Kaoru Ishikawa's cause-and-effect diagram, presented in 1968, carried the idea into manufacturing, sorting observable effects from their candidate causes across families such as method and machine so that teams stop treating the visible defect as the explanation.

Modern operations reframed the distinction around alerting. Google's Site Reliability Engineering practice argues for symptom-based alerting: page on what the user experiences, such as elevated latency or a failing checkout, and avoid alerting directly on every internal cause. The reasoning is that causes are many and shift as the system changes, while the symptoms that hurt users are few and stable. Rob Ewaschuk's "Philosophy on Alerting", which seeded the SRE book's monitoring chapter, makes the case that good alerts answer "what is broken, and why" by paging on the symptom and leaving the why to investigation🔍InvestigationEngineeringAn investigation into an issue or incidentView reference →.

The live tension is calibration. Alert only on symptoms and you learn late, after users are already hurting. Alert on every cause and you drown in noise and start ignoring the page. The accepted balance pairs symptom alerts for paging with cause signals for diagnosis once you are already looking.

How it works in practice

Checkout conversion drops six percent at 14:00. That fall is the symptom: it is what the business dashboard shows and what a monitor flags. It says nothing about why. The investigation finds three contributing conditions: a third-party fraud check has slowed, a retry loop is amplifying the load, and a recent deploy shortened the client timeout. The single visible symptom sat on top of a small cluster of causes. Had the team alerted on raw fraud-check latency alone, they would have paged nightly on blips that never reached a customer. Alerting on the conversion symptom paged them exactly when it mattered, and the investigation supplied the rest.

Symptom vs. its neighbours

• Root cause🪝Root CauseEngineeringAn identified root cause of an issueView reference → is the underlying condition the symptom points to. The root_cause🪝Root CauseEngineeringAn identified root cause of an issueView reference → explains the symptom; the symptom is the evidence trail back to it. One root cause can throw several symptoms, and several causes can converge on one.
• Incident🚨IncidentDevOps & PlatformA production incidentView reference → is the declared, time-bounded event a serious symptom opens. A symptom⚠️SymptomEngineeringA symptom of a problem is a signal; an incident is an organisational response with an owner and a timeline. A symptom can pass without ever becoming an incident.
• Monitor is the instrument that watches for a symptom and fires when thresholds break. The monitor📺MonitorDevOps & PlatformA monitoring checkView reference → is the sensor; the symptom is what it senses. A symptom nobody monitors is one nobody learns about until a user reports it.

In the graph

In the Unified Product Graph, symptom⚠️SymptomEngineeringA symptom of a problem sits in the engineering and reliability region as the observable layer of an incident chain. It is produced by root_cause_causes_symptomRoot CausecausesSymptomcausal and located by investigation_surfaces_symptomInvestigationsurfacesSymptomhierarchy. The watch comes from monitor_detects_symptomMonitordetectsSymptomcausal, and escalation runs through symptom_triggers_incidentSymptomtriggersIncidentcausal. Keeping the symptom as its own node, distinct from cause and incident, preserves the honest sequence of a diagnosis: a team can see whether a closed incident actually removed the underlying root_cause🪝Root CauseEngineeringAn identified root cause of an issueView reference → or merely silenced the symptom that exposed it.