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, withobserved, the band,breached, and arevisionthat 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.
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:
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.