Buttons can help you keep an unattended installation healthy by surfacing which connection needs attention, why, and giving you a one-click way to hand support everything they need. This page explains how to read a connection's status and logs, when Buttons restarts a connection automatically, and what to do when a connection needs your attention.
Each connection runs as its own process. Buttons always measures its CPU and memory use, and can warn you or restart the connection automatically if either stays too high. Both are off for a new connection: nothing warns or restarts until you turn a threshold on for that connection on its Monitoring tab. Once on, a restart threshold protects the rest of your system from one misbehaving connection, but it is not a general safety net. A connection that keeps failing for another reason, such as a wrong address or bad credentials, restarts every time it fails and keeps trying indefinitely. Buttons does not detect that pattern as a distinct problem or stop retrying on its own, so a failing connection needs you to notice it and fix the underlying cause.
Three places tell you what is happening:
The connection's status banner, such as Connected, Connecting, Disconnected, or Bad configuration.
Its CPU and Memory gauges, described below.
Its Connection Logs, filterable by level (Error, Warn, Info, Verbose, Debug).
Every connection shows a CPU and a Memory gauge: small ones on each row of the connection list, and larger ones at the top of the connection's detail view. Each gauge shows the connection's one-minute average use:
Green: below the connection's Warning level, or no thresholds turned on.
Amber: at or above Warning. Nothing happens automatically yet, but it's worth watching.
Red: at or above the Restart limit. Buttons restarts the connection.
With both thresholds off, which is the default, a gauge only shows usage and never turns amber or red.
The full width of a gauge is the restart limit, so a bar that's nearly full is close to a restart. (With restarts turned off, the scale runs a little past the warning level instead.) On the larger gauge in the detail view, a thin amber line marks the warning level. Hover over either gauge to see the Current average, the Warning level, and the Restart limit. A threshold that's turned off reads Off. A connection that has only just started shows Waiting for sample, then Collecting with its latest reading, until a full minute's average is available.
You set both levels per connection on its Monitoring tab, described next.
Each connection has its own Monitoring tab, with two groups of settings.
Logging: Keep historical log data ("Save connection log data for inclusion in support packages") is off by default. Turn it on for a connection you expect to need to hand to support later, so its history is in the support package.
Resource thresholds: CPU thresholds and Memory thresholds each have two switches, Warning and Restart, both off by default. Turning a switch on sets a starting value, which you can then change by dragging its marker on the slider:
Threshold
Starting value when turned on
Slider
CPU Warning
80%
5% to 100%, in 5% steps
CPU Restart
98%
5% to 100%, in 5% steps
Memory Warning
800 MiB
256 MiB to 16 GiB
Memory Restart
1 GiB
256 MiB to 16 GiB
The memory slider doubles from one mark to the next (256 MiB, 512 MiB, 1 GiB, 2 GiB and so on up to 16 GiB), with three stops between marks. Between 1 GiB and 2 GiB, for example, you can choose 1.25 GiB, 1.5 GiB or 1.75 GiB. Small amounts get fine steps and large amounts get coarse ones, so the whole range fits on one slider.
Note
Buttons shows memory in MiB (mebibytes) and GiB (gibibytes) rather than MB and GB. They're close but not identical: 1 MiB is 1,024 KiB, about 1.05 MB, and 1 GiB is 1,024 MiB, about 1.07 GB. The difference rarely matters when setting a threshold. Just read 1 GiB as "a little over 1 GB". Some system tools, such as Windows Task Manager, also count memory in 1,024s but label it MB and GB, so their numbers match Buttons even though the units are named differently.
The warning level always stays below the restart level. Buttons compares each level against the connection's one-minute average: reaching Warning flags the connection, and reaching Restart restarts it. The message names the average and the threshold, for example "Process tree CPU warning: one-minute average 83.0% exceeded threshold 80%". The measurement covers the connection's whole process tree, so it includes any helper processes a module starts.
A sensible starting point: turn on Warning for both on every connection you care about, so the gauges tell you when something drifts. Only turn on Restart for a connection known to leak or hang, where an automatic restart is safer than waiting for someone to notice.
Do not assume a quiet log means a healthy connection. Some failure modes only produce Debug-level messages, so a connection can be failing continuously while its Error and Warn filters show nothing.
A connection has been running for weeks without incident, with Warning and Restart thresholds turned on. Its CPU or memory use has been trending upward, and it has now restarted on its own.
Open Connect → Connection and select the connection. To spot it in the first place, scan the small gauges in the connection list for amber or red.
Look at the CPU and Memory gauges at the top of its detail view, and hover over them for the current average against the warning and restart levels.
Open the Monitoring tab and check its Resource thresholds: Buttons restarts the connection once its one-minute average reaches the Restart level.
Decide what the restart tells you:
If this connection is legitimately resource-heavy for what it does, raise its thresholds so routine use does not restart it as often.
If the trend looks like a leak or a stuck loop inside the connection itself, treat the restart as a symptom, not a fix: check for a newer module version or contact support with the connection's logs.
If the same connection has no thresholds turned on, it doesn't restart: its use keeps climbing until something else gives. Turn on at least Warning so the gauges tell you before that happens.
A connection has been failing to reach its target for some time without anyone noticing, because nothing about it looked urgent.
Open Connect → Connection and check each connection's status in the list, not just whether it appears Connected.
Select a connection whose status stays on Connecting rather than settling into Connected or Disconnected. That pattern (never resolving either way) usually means Buttons is retrying the same failure repeatedly.
Open Connection Logs and select All levels. A connection stuck like this can log only Debug-level reconnect entries, once per attempt, with nothing at Error or Warn.
Fix the cause directly: confirm the target address, credentials, and network path outside Buttons, then correct the connection's configuration. Restarting the connection does not help if the underlying cause is still there; it will simply resume retrying.
