Remote Session Limits & Auto-Disconnect

When a technician starts the built-in WebRTC screen-share against a managed machine, Athena governs how long that live session may run. A configurable maximum session duration ends an unattended-forgotten session automatically, a "Session ending soon" banner gives the technician a chance to keep working, and a reconnect window decides how long a brief network blip is tolerated before the session closes cleanly. This page explains each control, what the technician sees, and how an administrator sets the limits.

The session lifecycle at a glance#

Every screen-share session runs on a server-owned clock, so the limit is enforced regardless of what the technician's browser is doing:

• When the session starts, the server stamps a deadline = start time + maximum session duration. If the maximum is set to unlimited, no deadline is set.
• About 60 seconds before the deadline, the technician sees a "Session ending soon" banner with a Stay connected button.
• Choosing Stay connected resets the deadline to a fresh full duration from that moment, and the session continues.
• If nothing is done, the session is auto-disconnected at the deadline and a notice explains it ended because it reached its maximum duration.
• If the connection drops mid-session, the browser retries for the length of the reconnect window; if it can't re-establish in time, the session ends cleanly.

Maximum session duration#

The maximum duration is a hard auto-disconnect. It is enforced on the server: the server periodically checks active sessions and, once a session has reached its deadline, tears it down — closing the media stream and stopping the remote helper — even if the technician's browser is idle, minimized, or unresponsive. This bounds how long any single continuous session can hold control of a machine.

The "ending soon" warning & Stay connected#

Roughly one minute before the deadline, a warning banner appears at the top of the screen-share viewport so an active technician isn't cut off by surprise:

Clicking Stay connected extends the session — the server sets a new deadline a full maximum duration ahead and dismisses the banner. The warning will appear again about a minute before the new deadline, so a technician can extend as many times as the work requires. There is no fixed cap on the number of extensions.

If the technician does nothing, the session ends at the deadline and a notice is shown: "The session ended automatically because it reached its maximum duration."

The reconnect window#

Live media connections can briefly drop — a Wi-Fi handoff, a VPN hiccup, a momentary route change. Rather than kill the session at the first interruption, Athena lets the technician's browser keep trying to rebuild the connection for a bounded period. During this time an overlay reads "Connection lost — reconnecting…".

If the connection is restored within the window, the session resumes where it left off. If the window elapses without success, the session is closed and the technician sees "The session ended because the connection could not be restored." Time spent reconnecting does not extend the maximum-duration deadline.

No idle timeout#

There is intentionally no idle timeout on a screen-share session. A session is not closed simply because there was no mouse or keyboard activity — long-running remote work (a lengthy install, a wait for a reboot, watching a batch job) will not be dropped for being "quiet." The only automatic end conditions are reaching the maximum duration without extending, or exhausting the reconnect window after a connectivity drop.

Configuring the limits#

The maximum-duration and reconnect-window values are fixed session-lifecycle settings, read once when the server starts. They are set in the server configuration file appsettings.json under the RemoteSession section, or overridden with the matching environment variables, and take effect after a server restart:

// appsettings.json
"RemoteSession": {
  "MaxSessionDurationMinutes": 120,   // 2h; 0 or blank = unlimited
  "ReconnectWindowSeconds": 30,      // grace period after a drop
  "WebRtcEnabled": true              // master on/off for screen-share
}

Environment-variable form (useful for container deployments):

RemoteSession__MaxSessionDurationMinutes=120
RemoteSession__ReconnectWindowSeconds=30

Turning screen-share on or off#

The whole technician screen-share feature has a master switch, RemoteSession:WebRtcEnabled (default true). When it is off, the screen-share action is hidden on a machine's detail view and no sessions can be started, so the duration and reconnect limits do not come into play. This switch is surfaced on the Settings → Agents → Remotes → WebRTC Screen Share screen; the session-limit values above are the fixed configuration that governs any session it allows.

Auditing#

Screen-share activity is recorded in the audit log. Each session writes a start event and an end event; the end event carries how long the session lasted and why it ended — including when it was auto-disconnected for reaching its maximum duration or because a lost connection could not be restored. That makes it straightforward to review session length and auto-disconnects, and to forward the same detail to a SIEM. See the Audit Event Types Reference for the screen-share session events, and Session Recordings if you also capture the video of each session.