Skip to main content
A finding is one deviation of one series (signal, service, and environment) from its expected band. Squasher checks every service hourly against its own history. Anomalies are findings with source_kind set to anomaly. See Anomalies and findings for how the band and resolution work.

Operations

Reads need findings:read. findings.mute and findings.updateAnomalyPolicy need findings:write. A key with the read or write shortcut has them.

List findings

The response is { "data": [Finding], "next_cursor": string | null }. A finding has these fields: unit is ms, ratio (a fraction from 0 to 1, such as an error rate), or count.

Get one finding

findings.get returns { finding, evaluations, series, evidence }:
  • evaluations: each hourly evaluation, oldest first, with observed, the band, breached, and a revision that increases when late data changes an hour.
  • series: hourly values from 24 hours before the finding started to its end (or now), at most 7 days. Each point has the expected band of that hour.
  • evidence.deployments: up to 10 deployments from 6 hours before the first breach to 1 hour after the last one.
  • evidence.error_groups: up to 5 top issues of the service in that time.
A finding that is not in the project returns 404.

Mute a finding

until must be in the future and at most 30 days ahead. Send {"until": null} to unmute. A mute does not change the finding’s status. The response is the updated finding.

Anomaly policy

Anomalies do not open incidents by default. Send incident_rules with findings.updateAnomalyPolicy to open an incident for the signals and severities you choose:
An incident that a finding opens has the source type finding and uses the project’s notification routes and on-call paging.

CLI and MCP

policy set also takes --enabled, --timezone, --recovery-buckets, and --no-paging. In MCP Code Mode, call search("findings"). Related: Anomalies and findings, Incidents API.