Notification Reporting
Chute monitors connection quality, proxy availability, traffic patterns, and configuration health. When a significant anomaly is detected, the Chute app may display a system notification to alert you.
A single timeout or unreachable node will not trigger a notification — only sustained or large-scale patterns will.
Event Types
| Event | What It Means |
|---|---|
| Mass Connection Failure | A large number of connections are failing in the same way (e.g., all timing out). |
| Service Unavailable | A specific proxy node keeps closing connections without returning any data — the node is likely down. |
| Traffic Surge | Sustained high-bandwidth traffic (upload or download), significantly above the recent average. Instant spikes are ignored. |
| Config Auto-Update Failed | Managed configuration auto-update has failed repeatedly (download or parse errors). |
| Policy Group Switch | A policy group (Fallback / URL Test / Load Balance / SSID) automatically switched to a different proxy. If a group oscillates rapidly, a single "flapping" alert is shown instead of one per switch. |
| Egress IP Change | The public egress IP address observed for the connection has changed. |
| Tailscale DERP Home Change | The Tailscale engine switched to a different home DERP relay region. |
| Tailscale Diagnostics | Tailscale events such as exit-node problems or auth-key failures. |
Thresholds
The reporting system is enabled by default. Thresholds are built-in and not configurable via the configuration file. The reference values are:
| Threshold | Value | Unit | Description |
|---|---|---|---|
| Mass failure threshold | 20 | count | Minimum failures in the window to trigger a Mass Connection Failure alert |
| Mass failure rate | 0.3 | ratio (0–1) | Minimum failure rate (failures / total) for TCP connections |
| Mass failure window | 60 | seconds | Time window for counting mass failures |
| Service unavailable count | 3 | count | Failures on a single node before triggering a Service Unavailable alert |
| Service unavailable window | 300 | seconds | Time window for counting node failures |
| Traffic surge multiplier | 5.0 | ratio | Current rate must exceed the 5-minute average by this multiple |
| Traffic surge duration | 60 | seconds | How long the surge must be sustained before alerting |
| Policy flap window | 60 | seconds | Time window for detecting policy group oscillation |
| Policy flap threshold | 3 | count | Switches within the window that trigger a flapping alert |
| Cooldown interval | 120 | seconds | Minimum interval between successive alerts of the same type |
| Config failure count | 2 | count | Consecutive update failures (reset on any success) before triggering a Config Update Failure alert — there is no time window |
How Alerts Are Throttled
To avoid notification spam, Chute applies several safeguards:
- Cooldown: The same type of alert won't fire more than once per cooldown interval (120 seconds).
- Mass suppression: When a Mass Connection Failure alert fires, individual Service Unavailable alerts are suppressed — the mass alert already covers the problem.
- Anti-flap: If a policy group switches back and forth rapidly (3 or more times within 60 seconds), a single "flapping" alert is shown instead of one per switch.
- Grace period: Service Unavailable alerts are suppressed for 60 seconds after the engine starts or reloads a configuration, to avoid false alerts from startup connection churn.
- Network change reset: All internal counters are reset when the network changes (Wi-Fi ↔ cellular) or the configuration is reloaded, preventing stale data from triggering false alerts.