Browse documentation

Investigate

Review detected anomalies

Triage unusual metric behavior, confirm impact, and close findings without mistaking detection for cause.

Open Explore → Anomalies to review statistically unusual metric behavior. Findings can be open, acknowledged, or resolved.

Triage a finding

  1. Confirm the project, environment, metric, service, and time window.
  2. Compare the observed value with the expected band and surrounding baseline.
  3. Check related service health, traces, logs, Issues, releases, and alerts.
  4. Determine whether customers were affected or whether the change was expected.
  5. Acknowledge when someone owns the investigation; Resolve when the finding no longer needs action.

A detection says the series departed from its learned behavior. It does not establish a root cause and may reflect a deployment, traffic shift, seasonality, instrumentation change, or real failure.

Metric findings are isolated by the same canonical series identity used at ingestion: project, metric name, service, deployment environment, and the order-independent metric attribute map. The scanner evaluates only the 200 highest-volume recent series per organization, so detector work is bounded even when admitted metric attributes contain high-cardinality values. A finding and its incident event retain the service, environment, and exact metric attributes that were evaluated; same-name metrics from different services, environments, or attribute sets do not share a baseline.

Avoid noisy conclusions

  • Use a time window that includes the baseline and the deviation.
  • Check for changed metric labels or cardinality before blaming application behavior.
  • Compare the anomaly with a release or feature rollout.
  • Do not delete a finding merely because it is inconvenient; resolve it with the reason recorded in the team’s incident workflow.

If no findings appear, confirm metrics have enough consistent history for detection and that the selected status filter includes open findings.