> ## Documentation Index > Fetch the complete documentation index at: https://docs.squasher.ai/llms.txt > Use this file to discover all available pages before exploring further. # Anomalies and findings > See when a service's latency, error rate, traffic, or error logs leave their normal range, and choose which anomalies open incidents. 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: | Signal | What it measures | Unit | | - | - | - | | `latency_p95` | The 95th percentile request duration in the hour. | `ms` | | `error_rate` | The fraction of requests that failed in the hour, from 0 to 1. | `ratio` | | `traffic_drop` | Requests in the hour, when they fall far below the usual volume. | `count` | | `error_logs` | Error-level log lines in the hour. | `count` | | `traffic` | Requests in the hour, compared with the same hour on the same weekday. | `count` | `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: ```bash theme={null} squasher anomalies policy set --project "$SQUASHER_PROJECT_ID" \ --page error_rate:warning --page "*:critical" ``` An incident opened by a finding is a normal incident. Its `sourceType` is `finding`, and it goes through your [notification routes](/features/alerts) and [on-call](/features/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: ```bash theme={null} squasher anomalies policy set --project "$SQUASHER_PROJECT_ID" --no-paging ``` 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. ```bash theme={null} squasher findings mute --project "$SQUASHER_PROJECT_ID" --until 1d squasher findings unmute --project "$SQUASHER_PROJECT_ID" ``` `--until` takes an ISO time or a duration from now, such as `30m`, `2h`, or `1d`. ## List and inspect findings ```bash theme={null} squasher anomalies --project "$SQUASHER_PROJECT_ID" squasher findings list --project "$SQUASHER_PROJECT_ID" --status all --signal error_rate squasher findings get --project "$SQUASHER_PROJECT_ID" squasher anomalies policy get --project "$SQUASHER_PROJECT_ID" ``` `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](/api-reference/findings). In MCP Code Mode, call `search("findings")`. ## Next steps List findings and change the anomaly policy. Route incidents from anomalies to the channels your team watches. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.