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). |
| Proxy Node 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. |
| Configuration Update Failed | Managed configuration auto-update has failed repeatedly (download or parse errors). |
| Policy Group Primary Changed | A policy group switched to a different proxy — on its own (Fallback / URL Test / Load Balance / SSID), or because you selected another one by hand. If a group oscillates rapidly, a single "flapping" alert is shown instead of one per switch; on Chute Mac that alert has a switch of its own, Policy Group Flapping, which is off by default. |
| Network Address Changed | The addresses this device has on the network changed. The notification lists the IPv4 and IPv6 addresses separately. On Chute Android the event is Exit IP Changed instead: the public address traffic leaves from, a single address, and its switch is off by default. |
| Tailscale Home DERP Changed | The Tailscale engine switched to a different home DERP relay region. Recorded on every platform; Chute Mac raises a notification for it, and so does Chute Android, under its Tailscale Events switch, which is off by default. |
| Tailscale Events | Tailscale events such as exit-node problems or auth-key failures. |
| Rule Notification | A rule carrying notification-text= matched. Chute posts the text itself — see Rule Notifications — and records the event. |
| Network Not Carrying Traffic | Outbound connections keep timing out while nothing is received, although the system still reports the network as working — for example a stalled cellular link. Reported once per episode, and again only after traffic resumes or the network changes. Chute Mac has its own switch for it, on by default; on Chute iOS and Chute Android it follows the Mass Connection Failure switch. |
Rule Notifications
[Rule]
DOMAIN-SUFFIX,bank.example,DIRECT,notification-text="Bank site opened",notification-interval=60
A rule with notification-text= makes Chute post a system notification when it matches: the title is the text, the body is host:port → policy. Each rule notifies at most once per notification-interval seconds (default 300). These notifications, like the ones scripts post with $notification, follow the app's notification switch: Allow Notification on Chute iOS, Show report event notifications on Chute Mac, and on Chute Android the system's notification permission for Chute, where script notifications also have a channel of their own, Script Notifications. Turn it off and none are shown. Apple TV shows no notifications.
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 |
| Proxy node unavailable count | 3 | count | Failures on a single node before triggering a Proxy Node Unavailable alert |
| Proxy node 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 before the same alert fires again — see How Alerts Are Throttled |
| Config failure count | 2 | count | Consecutive update failures (reset on any success; a check that finds the address serving a Clash or sing-box profile counts as neither) 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 alert won't fire more than once per cooldown interval (120 seconds). "The same" means the same node, the same group switching the same way, the same kind of failure or the same configuration URL — a second node going down within the interval still gets an alert of its own. Tailscale Home DERP Changed has no cooldown, and a rule notification follows its own
notification-interval. - Mass suppression: When a Mass Connection Failure alert fires, individual Proxy Node 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: Proxy Node 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.