Periodic response gaps in a remote terminal: what they mean

Your remote terminal pauses, stops responding for a few seconds, then catches up or disconnects. When the gaps happen at regular intervals, it is tempting to blame the server, but a Wi-Fi link, VPN, router, or idle timeout can produce a similar pattern.

Start by checking whether your connection has pauses outside the terminal. The Connection Stability test tracks response time, jitter, lost requests, and dropouts over a few minutes. It tests your browser's connection to TooLab, not the route to your terminal host, so use it as a clue rather than a direct SSH test.

Check for response gaps

1. Open the Connection Stability test on the same computer and network you use for the remote terminal.
2. Keep the test page in the foreground and let it run for several minutes. Avoid downloads or other heavy network use during this first check.
3. Note when a dropout or sharp delay occurs. Compare its timing with a pause in the terminal, if one happens during the test.
4. Repeat the test while using the terminal normally, then compare the results. If possible, run another check on a wired connection or a different network.

A browser test cannot inspect your SSH packets or identify which device dropped them. Comparing results across conditions helps you locate the likely part of the connection.

What the result means

Lost requests or dropouts appear during the test

Your browser could not get some test requests through in time. If the terminal pauses at the same time, a shared network problem is plausible, such as a weak Wi-Fi link, router interruption, VPN tunnel, or internet connection issue. It does not prove the terminal's packets were lost, because the test and terminal may take different routes.

Response time jumps, but requests are not lost

The connection is still responding, but some responses take much longer than others. This variation is called jitter. A terminal may appear frozen while waiting for a response, then continue when it arrives. If the delay happens during uploads, downloads, or other busy network activity, congestion may be involved.

The test stays steady while the terminal pauses

The general connection to TooLab looks stable during the check, but the terminal's route or software may still be at fault. The host, VPN, remote access gateway, or terminal client may have an idle timeout or a brief service interruption. Ask whether other users on the same host see the same pauses, and check the host's logs if you manage it.

The terminal pauses at a regular interval

A repeated interval can point to a keepalive check, VPN rekey, firewall timeout, or scheduled network event. A keepalive is a small message used to check whether a connection is still active. Timing alone cannot identify which mechanism is responsible. Record the interval and whether the session recovers or disconnects.

How to narrow down the cause

1. Keep the computer awake during the test. Leave the browser tab visible and prevent the computer from sleeping. Background tabs and power-saving states can affect browser measurements, while sleep can interrupt a terminal connection.
2. Compare Wi-Fi with a wired connection. If the gaps stop on Ethernet, focus on Wi-Fi coverage, interference, or the wireless adapter. On Windows 11, check Settings › Network & internet › Wi-Fi. On macOS, check System Settings › Wi-Fi and compare from the same location.
3. Compare with and without the VPN, if permitted. Follow your workplace or network rules before disconnecting it. If the pauses occur only through the VPN, ask its administrator to check tunnel stability and idle-timeout settings. Do not send work traffic outside an approved VPN.
4. Pause other network activity. Stop large uploads, cloud backups, and downloads, then repeat the stability check. If the terminal behaves better, congestion may be increasing delay or causing brief timeouts.
5. Restart the router and reconnect. Restart it only if you are allowed to interrupt the network. Reconnect the computer and run the test again. If several devices lose connection at once, the router or internet service is more likely than the terminal client.
6. Check SSH keepalive settings with the host administrator. For an SSH client you control, a client-side setting such as ServerAliveInterval 30 can send periodic checks, but it will not repair packet loss or an unstable route. Ask before changing settings on a managed work system, and do not treat keepalives as a fix for a failing connection.

When to contact the network or host administrator

Share the exact times of the pauses, how long each one lasts, whether the session reconnects, and the results from Wi-Fi, Ethernet, and VPN comparisons. If several users see the same gaps, ask the administrator to check the remote host, VPN gateway, firewall, and logs for timeouts at those times. If only your device is affected, the network comparison can help show whether to focus on your computer or local connection.

For more ways to catch short interruptions, see how to catch internet disconnects that last only seconds.

Why the test and terminal can disagree

The Connection Stability test measures the path between your browser and TooLab's server. Your terminal may connect to a different city, data center, VPN gateway, or company network, and each route can behave differently. A clean test therefore does not clear the terminal host, and a lost browser request does not prove the SSH session lost a packet.

Use the test to establish whether your general connection is also having trouble. When results do not line up, compare another network or ask the administrator to check the terminal's own connection logs.