# Monitor and troubleshoot a connection

> How to read a connection's status and logs, when Buttons restarts it automatically, and what to do when it keeps failing.

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. Before you begin Access to Connect → Connection . For the last resort in this guide, access to Settings → General . How connection health works 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 ). Read the CPU and Memory gauges 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. Set up the Monitoring tab 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. Example: a connection's resource use is climbing 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. Example: a connection has been quietly failing 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. If you get stuck What you see What to try Status stays on Connecting and Error/Warn filters show nothing. Switch Connection Logs to All levels before concluding the connection is idle rather than failing. A connection keeps restarting on its own. Check its CPU and Memory gauges and Monitoring thresholds before assuming the module is broken: a gauge that reaches red has hit the restart limit. A gauge shows Waiting for sample or Collecting . The connection has only just started: the gauge fills in once a full minute of samples is available. In a High Availability deployment, a device can't reach a connection that listens for incoming TCP or UDP traffic on the virtual IP. Add a port forwarding rule for the connection's listening port, and point the device at the cluster's virtual IP. See Forward incoming traffic to a connection in an HA deployment . You cannot identify the cause yourself. Open Settings → General and select Export Support Package to download a ZIP you can send to Bitfocus support. Where to go next Add an ATEM connection if you are setting up a new connection rather than troubleshooting an existing one. Update a connection's module safely , if the problem might be the module version itself. Forward incoming traffic to a connection in an HA deployment , if devices connect in to the connection.