ExplanationHow a cause is ranked and checkedWorked example · INC-20931

Evidence first. Then a conclusion you can check.

MonitOps ranks probable causes from the metrics, logs, changes and topology behind each one, and classifies each cause: your application, your integration layer, or an external provider. The ranking is computed in code from named features; the AI investigator then confirms or refutes each candidate with cited evidence, and code validates what it cites. Relative confidence compares candidates with each other and is never shown as a probability. Every piece of evidence reopens the query that produced it. When the evidence is thin, MonitOps says so instead of guessing.

Candidates

Candidates are the symptom and everything upstream of it.

The candidates are the symptom entity and every entity upstream of it on the service map, up to three hops away, using declared and observed edges as they stood when the incident opened. For INC-20931, whose shared path is checkout-web → order-api → payments-gw, the candidates include order-api and payments-gw.

Card checkout · dependencies

INC-20931 path in bold · select a service

Incident path
Observed from traffic
Declared
Stale

payments-gw

External provider gateway · probable cause #1

Health: Down · 5xx on 31 % of calls since 14:01:58
Cause: Provider · relative confidence 0.81
Owner: Payments integration
Journeys: Card checkout
Provider: Status page: degraded card authorisation since 13:59
Edge: From order-api · observed, last seen 14:01

Reach: The symptom entity and every entity upstream of it on the service map, up to three hops away.
Edges: Declared and observed edges, as they stood when the incident opened. Observed edges come from traces; logs and service names alone never create one.
Outside: Entities classified as external stay off the map and out of cause assessment unless an administrator maps them in.
Service context: A service carries the journeys it serves, who owns it and what changed recently. Opening it leads to its logs, metrics and traces.
A missing edge: It can hide a dependency, which is why declaring a relationship that traces cannot show matters.

Fig. 1 — Card checkout. The INC-20931 path is in bold: checkout-web, order-api, payments-gw. Select a service to see where each fact came from.

Features

Each candidate is scored from named features.

The ranking is computed in code from named features, each normalised to the same range. A weighted combination of them gives every candidate a raw score; the weights are configuration.

Feature	What it measures
Provider status	Whether the provider reported an incident on the candidate or its parent system in the window; maintenance counts for less.
Change	Whether a recent change touched the candidate.
Temporal	Whether the candidate’s anomaly began before the symptom’s; the closer, the higher.
Error signal	New error signatures against the baseline, or a new operational event.
Severity	How strongly the candidate’s signals departed from their baseline.
Proximity	How close the candidate is to the symptom on the map; the symptom itself is closest.
Evidence support	Added after investigation: evidence that supports the candidate raises it, evidence that refutes it lowers it.

Fig. 2 — The seven features, each normalised to the same range. Evidence support is added after investigation.

Relative confidence

Relative confidence ranks candidates against each other.

The scores are compared across the whole candidate set to give relative confidence, before the top three are selected. The assessment returns the top three with each one’s feature breakdown, the number of candidates considered and whether the evidence is sufficient. It is never shown as a probability.

Ranked candidates

payments-gw

provider

0.81Relative confidence

Contributing features: provider status · temporal · error signal

1Metric ·payments-gw 5xx responses 31 % (baseline under 0.5 %) since 14:01:58
2Log ·order-api: upstream timeout calling payments-gw (8000ms) ×1,284 in 4 min

payments-gwprovider0.81
order-apiintegration0.12

Fig. 3 — INC-20931 at 14:03:05. 0.81 ranks payments-gw above order-api (0.12). Relative confidence is not a probability, and a high value alone does not establish a cause.

Cause class

A cause class needs affirmative support.

Each candidate is classified from the same features as application, integration or provider. A high ranking alone does not earn a class that needs support: an integration classification needs affirmative evidence, and a provider classification needs a relevant provider incident and matching symptom evidence.

Cause class	Rule
application	Your own application. Entity type locates a hypothesis; it does not confirm a cause.
integration	Needs affirmative support, not only a high ranking.
provider	Needs a relevant provider incident and matching symptom evidence. Maintenance alone is context, not proof.

Fig. 4 — Each candidate is classified from the same features. The incident uses the class of its leading supported candidate: provider, for INC-20931.

The investigator

The investigator confirms or refutes with cited evidence.

An AI investigator takes the top candidates and tries to confirm or refute each with evidence from logs, metrics, changes and topology. It cannot change the ranking by assertion: code validates what it cites. What MonitOps measured, what it infers and what has been confirmed are labelled differently wherever they appear.

Observed
payments-gw 5xx 31 %
Probable
provider fault · relative confidence 0.81
Confirmed
recovered 14:09:52, verified by probes

Tests: Takes the top candidates and tries to confirm or refute each with evidence from logs, metrics, changes and topology.
Validated in code: Every cited result is checked against explicit support and refutation rules before it can affect the ranking. Assertions that fail validation contribute nothing.
Cannot set: A score, a confidence or a class.

Fig. 5 — The same incident, three kinds of statement. The label and icon tell them apart, not colour. Explanations written by MonitOps carry an AI-generated label.

Logs

Thousands of log lines, read as a handful of templates.

Logs in the incident window are grouped into templates with counts and first-seen times, and summarised with citations back to the lines that matter. Counts and times are computed in code from the stored log records.

Log templates

Incident window

Count	First seen	Template
1,284	14:01:58	upstream timeout calling payments-gw (<*>ms)
212	14:02:03	order <> payment state=PENDING retry=<>
9	14:02:40	circuit open: payments-gw

Count: How many lines in the window match the template.
First and last seen: The earliest and latest matching line in the window.
Baseline completeness: How complete the baseline for the template is.
Summary: An AI-written account of what changed in the window. It cites template identifiers, and every cited template exists in the computed set.
Gaps: Truncation, an uncovered interval and stale data are marked in the view. Partial data is never presented as complete.

Fig. 6 — Log templates of the incident window. In INC-20931 the order-api template upstream timeout calling payments-gw appears 1,284 times in 4 minutes.

Evidence

Every evidence link reopens its source.

An evidence reference binds the tenant, the entity, the time window and where the data came from. Opening it reruns the query or loads the record, and the request is authorized again for the person opening it.

Reopens
A signal query over a window
Entity
payments-gw

Window and tenant: Bound into the reference, with the entity and where the data came from.
Access: Authorized again for the person opening it. A reference carries no raw log text and no role.
Expired: If the telemetry has been deleted, the link says so.

Fig. 7 — The four pieces of evidence behind payments-gw. Open a row to see what its link reopens.

Thin evidence

When the evidence is thin, MonitOps says so.

When the evidence does not support a ranking, the assessment says so and lists what is missing. If the investigator is unavailable, the computed ranking is shown and marked as such.

Insufficient evidence

Insufficient evidence to rank a cause. Missing: provider status feed (stale 42 min).

Investigator unavailable

Investigator unavailable. Showing the computed ranking only.

Insufficient evidence: The assessment says so and lists what is missing. It does not force a cause, even when one candidate ranks highly.
Investigator unavailable: The computed ranking is shown and marked as such. Detection, correlation and scoring continue; only the confirmation or refutation is missing.
Late evidence: When evidence arrives late, such as provider event logs, the scorer runs once more on the updated inputs. The re-run is recorded on the incident timeline.

Fig. 8 — Two states from other incidents. In both, MonitOps shows what it has and says what is missing.

Where to go next

From an explanation to a question, or to an action.

Operators ask the copilot what they would ask a colleague, and it cites every claim. An action that changes production is proposed with its evidence and waits for a person to approve it.

Continue on the site

Read the documentation

Fig. 9 — On from an explanation: to a question, to an action, or into the documentation.

See MonitOps on your own incidents.

We run a working session with your operations team on your services and recent incidents.

Contact sales Log in