Skip to main content
Squasher checks every production service hourly against its own history. When a measured value leaves the range that is normal for that service, Squasher records a finding. You do not set a threshold. In the dashboard, open Anomalies in the project sidebar to see open and resolved findings. Each finding page shows the hourly values against the expected band, deployments and errors from the same time, and the linked incident. From there you can investigate with Squasher Agent, create an alert from the finding, or mute it. The Overview page shows the open anomalies. Change the policy in Settings > Incidents > Anomalies.

​
What a finding is

A finding is one deviation of one series: a signal, for one service, in one environment. It starts with the first hourly evaluation outside the expected band. It stays open until the value is back inside the band for a number of hourly evaluations in a row. Anomalies are findings with source_kind set to anomaly. These are the signals that Squasher checks: traffic can be above or below the band. direction on a finding says which side the value is on.

​
How the expected band works

Each check compares one complete hour with the service’s own history:
  • The hourly baseline compares the hour with the last 7 days of the same service and environment.
  • When a service has at least 14 days of history, a seasonal check also compares the hour with the same hour of the week. Use the policy timezone to set which local hour that is.
Each finding stores the observed value, the expected band (expected.low, expected.high), the baseline, a severity of warning or critical, and a score. A larger score means the value is further from normal. Use the score only to sort findings. Squasher evaluates an hour only when its data is complete. data_watermark shows the newest data that was complete at the last evaluation. When late data arrives, Squasher checks the hour again and records a new revision of that evaluation.

​
When a finding resolves

A finding resolves when the value is back inside the band for recovery_buckets hourly evaluations in a row. The default is 2. A new breach before then restarts the count. resolved_reason is returned_to_band for a normal recovery. It is corrected when late data showed that the value never left the band.

​
Open incidents from anomalies

Anomalies do not page anyone by default. A new project has no incident rules, so findings appear in the dashboard, the API, the CLI, and MCP, but they do not open incidents. To page on anomalies, add incident rules to the project’s anomaly policy. Each rule names a signal (or * for every signal) and the lowest severity that opens an incident:
An incident opened by a finding is a normal incident. Its sourceType is finding, and it goes through your notification routes and on-call paging. You acknowledge and resolve it on the incident. A finding links to at most one incident. To stop paging on anomalies again, remove every rule:
Set enabled to false to turn off anomaly findings for the project.

​
Mute a finding

Mute a finding to stop it from opening an incident until a time. The mute does not change the finding’s status. A mute can last at most 30 days.
--until takes an ISO time or a duration from now, such as 30m, 2h, or 1d.

​
List and inspect findings

squasher anomalies lists open anomaly findings and takes the same filters as squasher findings list. findings get returns the hourly evaluations, the hourly series with the band around the finding, and the deployments and top issues of the service in that time. The API has five operations: findings.list, findings.get, findings.mute, findings.getAnomalyPolicy, and findings.updateAnomalyPolicy. See the Findings API. In MCP Code Mode, call search("findings").

​
Next steps

Findings API

List findings and change the anomaly policy.

Set up notifications

Route incidents from anomalies to the channels your team watches.