An alert can report a real condition and still lead a team toward the wrong conclusion.
CPU utilisation may be elevated. Request volume may have doubled. A queue may be growing faster than usual. None of those observations is necessarily incorrect. The mistake begins when an observation is treated as a complete explanation.
Operational signals tell us what a system can measure. An investigation must determine what those measurements mean now.
The Alert Is Evidence, Not the Situation
An alert is created from a rule: a threshold was crossed, a state changed, or an expected event did not occur. It is an important piece of evidence, but it represents only the perspective of the system that produced it.
Consider an application experiencing an unusual increase in traffic. Its monitoring platform reports:
- Elevated CPU and memory utilisation
- Increased request latency
- A higher rate of queued work
- No corresponding increase in error rate
The alert is valid. The system is operating outside its normal baseline.
But several explanations remain possible:
- A component is degrading.
- A recent deployment changed resource consumption.
- A scheduled campaign is generating legitimate demand.
- An upstream system is retrying failed requests.
- Suspicious or unintended traffic is creating load.
- The current baseline no longer reflects normal operation.
The metric alone cannot distinguish among them.
Four Forms of Context
A useful investigation can draw from four broad forms of context. They do not need to live in one platform, and they should not be treated as equally relevant to every situation.
Operational signals
Telemetry, logs, alerts, events, traces, configuration state, and dependency health describe what systems are observing.
These sources can show that a condition exists and reveal relationships across components. They may still disagree because of collection delays, different sampling windows, or distinct views of the same event.
Business context
Campaigns, customer commitments, service-level objectives, planned launches, calendar activity, and current priorities describe what is happening around the system.
This context changes interpretation. Higher traffic during a planned commercial event may be expected. The same increase on an ordinary day may demand a different investigation.
Business context explains circumstances; it does not excuse harm. A planned event does not make severe latency, customer impact, or an SLA breach acceptable.
Operational knowledge
Runbooks, maintenance records, architecture documents, historical incidents, spreadsheets, and known dependencies preserve what the organisation has already learned.
This knowledge can reveal that a similar pattern occurred after an earlier configuration change or that a scheduled process is known to create temporary pressure. It can also be stale, incomplete, or contradicted by current evidence.
Human context
Questions, ownership, experience, feedback, and review contribute information that connected systems may not contain.
An engineer may know that a maintenance task was delayed. A service owner may clarify that a customer event began earlier than recorded. Human input can resolve ambiguity, but it should remain traceable rather than silently becoming a permanent assumption.
A Campaign-Day Example
Imagine that an alert fires because application load and latency have risen sharply.
An isolated workflow sees:
CPU threshold breached
→ probable capacity incident
→ escalate
A contextual investigation asks a wider set of questions:
- Did traffic volume change at the same time?
- Is a campaign, release, maintenance window, or customer event active?
- Are errors increasing, or is the system continuing to serve requests?
- Are all regions and customer groups affected equally?
- Did configuration or dependency state change before the spike?
- Has this pattern occurred during comparable events?
- Is the current behaviour within the organisation's accepted operating boundaries?
The calendar shows that a major shopping campaign began shortly before the alert. Request volume and completed transactions increased together. Error rates remain stable, but latency for one customer segment is approaching its service objective.
The campaign is now a strong explanation for the load increase—but it is not the final conclusion. The investigation still needs to determine whether the system is coping with expected demand and whether customer impact requires action.
Context Must Be Selected, Not Collected Indiscriminately
More information is not automatically better context.
An agentic investigation should retrieve information according to the questions it is trying to answer. It should evaluate:
- Relevance: Does this evidence help distinguish between plausible explanations?
- Recency: Is it current enough for the situation being investigated?
- Authority: Is the source reliable for the fact it is being used to support?
- Consistency: Does it agree with other evidence?
- Specificity: Does it apply to the affected service, location, customer, or time window?
- Completeness: What necessary information is still unavailable?
A calendar entry can indicate that a campaign was planned. Live traffic shows whether it actually began. Customer-impact data shows whether the system is meeting its obligations. Each source answers a different question.
From Retrieval to Investigation
Connecting sources is only the beginning. Context becomes useful when it changes how explanations are evaluated.
An agentic investigation can:
- Plan around the initial signal and available evidence.
- Retrieve relevant context through connected tools, knowledge retrieval, or agent collaboration.
- Correlate events, entities, dependencies, and time windows.
- Form several plausible explanations.
- Seek evidence that supports or contradicts each explanation.
- Identify missing, stale, or conflicting information.
- Prepare findings, uncertainty, and suggested areas for review.
This is different from attaching a larger payload to an alert. The objective is not to show everything that might be related. It is to determine which evidence changes the interpretation of the situation.
Google's Site Reliability Engineering guidance similarly warns that correlation does not establish causation and recommends testing hypotheses during troubleshooting. The distinction matters because two events may move together while sharing another cause.
What the Human Should Receive
The output of the investigation should not be an unexplained declaration. It should help a reviewer understand:
- What was observed
- Which context was considered
- Which explanations were tested
- What evidence supports the leading explanation
- What evidence contradicts or weakens it
- Which information remains unavailable
- Where customer or operational impact may require attention
For the campaign-day example, an appropriate review brief might state:
The load increase aligns with the scheduled campaign and is supported by a corresponding rise in completed transactions. Error rates remain stable. Latency is increasing for one customer segment and is approaching its service objective. No deployment or configuration change was found in the preceding window. Review capacity and customer-impact thresholds if the current trajectory continues.
The brief does not claim that the campaign makes the alert harmless. It gives the reviewer a grounded explanation, the remaining risk, and the evidence needed to decide what happens next.
Better Context Produces Better Questions
The value of connected context is not that it guarantees a perfect answer. Its value is that it enables a stronger investigation.
The monitoring signal asks, “Which threshold was crossed?”
The investigation asks:
- What changed?
- What is happening around the system?
- Which explanations fit all available evidence?
- What contradicts the leading explanation?
- What remains uncertain?
- What deserves human attention now?
An alert can be correct without being sufficient. Closing that gap requires more than another dashboard. It requires a system that can retrieve relevant context, reason across it, expose uncertainty, and prepare the result for human judgment.
References
- Google Site Reliability Engineering — Effective Troubleshooting. Guidance on hypothesis-driven troubleshooting and the distinction between correlation and causation. View source
- NIST AI Risk Management Framework Core. Guidance on interpreting AI output within its context, documenting systems, and defining human oversight responsibilities. View source
- NIST AI RMF Appendix C — AI Risk Management and Human-AI Interaction. Discussion of human roles and the loss of necessary context in data-driven representations. View source