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. |
Configuration
The reporting system is enabled by default with built-in thresholds. You can adjust the sensitivity via the [Report] section:
[Report]
mass-failure-threshold = 20
mass-failure-rate = 0.3
mass-failure-window = 60
service-unavailable-count = 3
service-unavailable-window = 300
traffic-surge-multiplier = 5.0
traffic-surge-duration = 60
policy-flap-window = 60
policy-flap-threshold = 3
cooldown-interval = 120
config-failure-count = 2
config-failure-window = 60
Parameters
| Parameter | Default | 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 | Update failures in the window before triggering a Config Update Failure alert |
config-failure-window |
60 | seconds | Time window for counting config update failures |
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. - 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 (≥
policy-flap-thresholdtimes withinpolicy-flap-window), 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.