Session timeout

The revised value is the only one that matters

Servers clamp the request to their own configured minimum and maximum, so asking for ten minutes on a server capped at sixty seconds gives you sixty seconds. Every client timer - keep-alive period, reconnect deadline, watchdog - must be derived from RevisedSessionTimeout returned in the CreateSession response, not from the value you asked for. Getting this wrong produces sessions that die on a healthy network.

What counts as activity

Any service request on the session resets the timer. An outstanding Publish request counts in most implementations, but relying on that alone is fragile: a subscription that has been deleted server-side leaves you with no traffic at all. The robust pattern is an explicit periodic read of Server, ServerStatus, CurrentTime at roughly a third of the revised timeout, which also gives you a clock-skew measurement for free.

Long timeouts have a cost

Generous timeouts help clients survive outages, but a crashed client's session survives just as long, holding its subscriptions, its monitored items and a slot in the server's MaxSessions budget. On a server with a modest session limit, a client that restarts faster than the timeout can exhaust the limit with its own orphans and get BadTooManySessions against itself.

Example

Deriving your timers from the revised value

Requested  60000 ms
Revised    30000 ms   <- the server's cap; this is what runs

Keep-alive read interval   ~10000 ms   (revised / 3)
Failures before reconnect  3
Effective detection time   ~30 s, matching the session lifetime

Timer built on 60000 instead: two keep-alives inside a 30 s window is not
enough margin, and the session dies while the network is perfectly healthy.

Defined in: Part 4 - Services, CreateSession and the session lifecycle.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.