Review detected anomalies

Anectico detects statistically unusual metric behavior and records each detection as a finding. Findings can be open, acknowledged, or resolved. Your agent reads the findings, checks the evidence around them, and changes their status after a preview.

Ask your agent

List the open anomaly findings from the last day, most likely real first. For the top one, check the service health, the traces, and the releases around that time. Tell me whether customers were affected. Do not change anything yet.

Job	MCP tool or action	CLI command
List findings, optionally by status, signal, and severity	list_anomaly_findings	anectico anomalies list
Read one finding whole	get_anomaly_finding (a read action)	anectico anomalies get
Acknowledge, resolve, or reopen a finding	set_anomaly_finding_status (a write action)	anectico anomalies ack, anectico anomalies resolve
Delete a finding	delete_anomaly_finding (a write action)	anectico anomalies delete
Check the evidence around a finding	get_service_health, search_traces, list_releases	anectico services list, anectico traces search, anectico releases list

Reading findings needs anomalies:read. Changing a status needs anomalies:write. Deleting needs anomalies:delete. MCP calls also need mcp:read or mcp:write. Both writes show a preview and need its confirmation token.

What your agent gets back

A finding has its signal, metric, severity, score, detection time, and a plain-English explanation. The list is ordered by detection time, newest first. A finding with no expected band or no rank says so. It does not show zero. The tool also reports the ranking fields, which are described below.

Open the proof

A finding has no page of its own. To check the series behind it, ask the agent to chart the metric on a dashboard and open the dashboard page from the link the agent returns. See Explore and compare metrics. A finding that was promoted to an incident has an incident page, at /view/incident/:id. Use the link from get_incident. Both pages are read-only. See Proof pages.

Triage a finding

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

A detection says that the series departed from its learned behavior. It does not establish a root cause. It can reflect a deployment, a traffic shift, seasonality, an instrumentation change, or a real failure. Expected bands use earlier observations and account for normal variation across comparable intervals. A few unusually quiet observations at the same time of day should not make ordinary noise look like a change. When comparable intervals show measurable variation, noisier times of day have a limited influence, so changes during quieter periods remain detectable. The newest observation is excluded from the band that is used to judge it. Acknowledging keeps the same finding active for deduplication and automatic recovery. It does not open a duplicate on the next detection, and it does not stop the detector from resolving the finding when the series returns in band. The audit identity and time come from the principal of the credential and from Anectico’s clock.

The first acknowledgment wins. Acknowledging a finding that is already acknowledged, or resolving one that is already resolved, changes nothing and keeps the original person and time. A resolved finding cannot be acknowledged. Reopen it first (set_anomaly_finding_status with open). Reopening clears who acknowledged and resolved it. It is refused while a newer active finding already tracks the same series, because that one is the finding to work.

The "Likely real" marker

Some findings carry a Likely real marker with a compact rank beside it, such as 2.7/3. In the tool result these are the fields likely_real and actionability_score (0 to 3). The marker means that a ranking model read the finding’s series (its recent history, its shape, and how often it has fired before) and is confident that this one is a real fault, not the detector reacting to normal variation. It exists to move the findings that most deserve attention to the top of the list. For this reason the marker exists only in the affirmative.

Nothing is ever marked as noise, hidden, or demoted. A finding without the marker is one that the ranking did not promote. This covers a finding that ranked below the bar, a finding that is not ranked yet, and a finding that could not be ranked at all. The three cannot be told apart in the list, on purpose. The ranking is reliable when it says "this is real". It is not reliable enough to be trusted when it says the opposite. Every finding the detector opened is in the list, with its full evidence. Acknowledging and resolving work the same way for all of them.

The list is ordered by detection time by default. Ask for the order actionability (CLI: anectico anomalies list --sort actionability) to bring marked findings to the top. Unranked findings sort to the bottom of that view. They do not disappear from it. Both orders return the same findings.

A finding may say that it is unranked, and why. Ranking not configured means that 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 that your plan’s daily cap for these judgments is spent, and ranking resumes at midnight UTC. See limits for the cap per plan. Ranking switched off means that ranking has been turned off for your organization and will not resume until it is turned back on. Ranking credential rejected means that the ranking service refused your deployment’s access and an operator has to fix the setup. Neither of these two clears on its own. Ranking unavailable means that a rank could not be produced. The finding is picked up again on a later pass. This can also happen when a derived trend is too large to represent. The recorded measurements remain available, and retrying the same history does not make that trend rankable. 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 that is used at ingestion: the project, the metric name, the service, the deployment environment, and the order-independent metric attribute map.

Detection is budgeted, so not every series that 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), not across the organization as one pool. Every namespace that is 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 writes thousands of times more. 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. Every namespace is therefore reached within a few passes, and the same ones are not 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, not as a reason to skip the metric. A metric that is missing more than that, or that reports on an irregular schedule, is not evaluated on that pass. 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 that is 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. A fast-reporting metric therefore 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 keep the service, the environment, and the non-content metric attributes that were evaluated. A metric attribute named after a recorded-content convention is not copied into the finding, the incident title, the timeline, or the notification. The opaque series identity still includes the full admitted attribute map. Same-name metrics with different underlying attribute values therefore 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 you blame application behavior.
• Compare the anomaly with a release or feature rollout.
• Do not delete a finding only because it is inconvenient. Resolve it with the reason recorded in the team’s incident workflow.

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

• Investigate service health and dashboards
• Explore and compare metrics
• Check rollout health
• Handle incidents and on-call