# Review detected anomalies > Triage unusual metric behavior, confirm impact, and close findings without mistaking detection for cause. Canonical page: https://anectico.com/docs/investigate/anomalies/ Open **Alerts → 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. Acknowledging keeps the same finding active for deduplication and automatic recovery; it does not open a duplicate on the next detection or prevent the detector from resolving it when the series returns in band. Audit identity and time come from the signed-in principal and Anectico's clock. ### The "Likely real" marker Some findings carry a **Likely real** marker with a compact rank beside it, such as `2.7/3`. It means a ranking model read the finding's series — its recent history, its shape, how often it has fired before — and is confident this one is a real fault rather than the detector reacting to normal variation. It is there to move the findings most worth your attention to the top of the list, which is why the marker exists only in the affirmative. **Nothing is ever marked as noise, hidden, or demoted.** A finding without the marker is one the ranking did not promote — which covers a finding ranked below the bar, a finding not yet ranked, and a finding that could not be ranked at all. The three are deliberately indistinguishable in the feed, because the ranking is reliable when it says "this is real" and not reliable enough to be trusted when it says the opposite. Every finding the detector opened is in the list regardless, with its full evidence, and acknowledging and resolving work the same way for all of them. The list is ordered by detection time by default. Switch the order to **Rank** to bring marked findings to the top; unranked findings sort to the bottom of that view rather than disappearing from it. The order lives in the page URL, so a ranked view can be shared or bookmarked. A finding may say it is unranked and why. **Ranking not configured** means ranking is not enabled for your organization; it is not a setting you can change, so ask support if you expected it. **Daily ranking cap reached** means your plan's daily cap for these judgments is spent and ranking resumes at midnight UTC — see [limits](/docs/reference/limits) for the cap per plan. **Ranking unavailable** means the ranking service could not answer this time; the finding is picked up again on a later pass. A finding that shows nothing at all is simply waiting its turn. Detection itself is never affected: a finding is opened, deduplicated, promoted to an incident and resolved exactly as it would be with ranking switched off entirely. 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. Detection is budgeted, so not every series an organization writes is evaluated on every pass. The budget is spent **per metric namespace** — the first two dot-separated segments of a metric name — rather than across the organization as one pool, and every namespace present is guaranteed at least one slot before any namespace gets a second. Within a namespace, the busiest series are evaluated first. This is why a quiet metric in its own namespace is still checked even when another namespace is writing thousands of times more, and it also bounds detector work when metric attributes contain high-cardinality values. When an organization has more namespaces than the budget has slots, successive passes start at a different point in the namespace order, so every namespace is reached within a few passes rather than the same ones being checked every time. A namespace that is not evaluated on one pass is evaluated on a later one. A metric that occasionally reports nothing for an interval is still evaluated: a small number of missing intervals — up to a tenth of the window, and no more than three in a row — is treated as a gap in reporting rather than as a reason to skip the metric. A metric missing more than that, or reporting on an irregular schedule, is not evaluated on that pass, because a detection over an unevenly spaced history would be a guess presented as a measurement. A detection is always taken on the last **complete** interval, never on the one still filling: a partly-collected interval reads low and would be reported as a drop that is not happening. The interval size follows the metric's own reporting cadence — 15 minutes for a metric reported every five minutes or faster, up to an hour for slower ones — so a fast-reporting metric does not wait out an hour to be checked. Expect a finding within roughly 25 minutes of the point that caused it for a fast-reporting metric. A finding and its incident event retain the service, environment, and non-content metric attributes that were evaluated. A metric attribute named after a recorded-content convention is not copied into the finding, incident title, timeline, or notification. The opaque series identity still includes the full admitted attribute map, so same-name metrics with different underlying attribute values do not share a baseline even when a classified value is withheld from the finding. ## 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. - [Investigate service health and dashboards](/docs/investigate/service-health-and-dashboards) - [Explore and compare metrics](/docs/investigate/metrics) - [Check rollout health](/docs/investigate/rollout-health) - [Handle incidents and on-call](/docs/respond/incidents-and-on-call)