Signed-in devices

A sign-in to Routy lasts until it has been idle for seven days. Nothing else ends it — there is no logout in the product today, and closing the browser does not sign anyone out.

So when someone signed in on a shared computer, lost a laptop, or thinks their account is being used by somebody else, the fix is to end the sessions. Signed-in devices is where you do that, and it is reachable from two places: the row menu on Users (under System Admin), and the Users tab of an affiliate.

An account manager can only open this for users of the affiliates in their own scope. A user outside it is reported as not existing rather than as forbidden, so an unexpected "not found" on a user you can see elsewhere usually means a scope problem, not a missing account.

What a device row tells you

Each row is one live session — one device that can still get fresh access tokens.

• The device — browser and operating system, like "Chrome on macOS". Both are worked out from the user agent the browser sent, and an unrecognised one shows as Unknown device. That is not a fault; some browsers and most automated clients do not identify themselves usefully.
• The address — the IP the device signed in from. If the device has since moved, the current address is shown after it. Either can be unknown when no address could be resolved, which happens with some mobile networks and corporate proxies. Treat an address as an indicator, never as proof of where someone is.
• Signed in — when the sign-in happened.
• Last active — when the device last renewed its access.

"Last active" is almost always recent, and that is normal

A signed-in browser renews its access in the background every few minutes, so any open tab looks active whether or not anybody is using it. A timestamp from ten minutes ago does not mean the session is stale or ending; it means the device is closed or asleep.

Do not read Last active as "when the person was last working". It answers a narrower question: when this device last checked in.

Older sessions that cannot be listed

If the list says some older sessions cannot be shown on their own, those are live sessions from before Routy recorded them individually. They are real and they still work, but there is no row to act on, so they can only be ended with Sign out all devices.

You should not normally see this. If you do, the count is the honest number of places the account is signed in that the list cannot show you.

Sign out

Sign out on a row ends that one device. Sign out all devices ends every session the user has, including the older ones above.

Three things to be clear about with the person you are helping, because all three get misread.

API keys keep working. Signing out devices has no effect on API tokens, and nothing on this screen touches them. An integration that authenticates with a key carries on exactly as before. If the concern is that a key has leaked, that is a different screen and a different credential.

This is not a password change. A signed-out device can sign straight back in with the same password. If you believe the password itself is compromised, it has to be changed as well — and changed after signing the devices out, so the new password is never typed on the device you are trying to remove.

Signing out does not lock the account. Ending sessions and disabling a user are separate actions. If what you actually need is "remove this person's access", you need to do both.

"May stay active for a few more minutes"

Sometimes a sign-out reports that the device may stay active for a few more minutes. This is a success, not a failure. The session is over and cannot renew itself; what could not be confirmed is cutting off an access token that had already been issued, and one of those expires on its own within about six minutes.

There is nothing to retry. If you need the access gone this second rather than within a few minutes, disable the user as well.

If you see this message on every attempt rather than occasionally, raise it with engineering — it points at something not reaching every instance, rather than at this account.

"Nothing to sign out"

The session had already lapsed by the time the request landed. Nothing was wrong and nothing needs doing; the list will no longer show it.

Session Control

Session Control (under System Admin → Administrator) signs out every user on the platform. It is a break-glass control for a platform-wide credential problem, not a routine cleanup, and it is limited to system administrators.

Everyone on the product has to sign in again afterwards. They can do so immediately, with the same passwords — this buys you the end of every current session, nothing more. API keys and integrations are unaffected here too.

A reason is required and goes on the audit trail. Write what actually prompted it; it is the only record of why every customer was signed out on a given afternoon.

Sign out my own session too is off by default, which is what keeps you signed in to the screen you are working on. Leave it off unless you specifically want to be included.

When to escalate to engineering

• A sign-out keeps reporting that access may persist, every time, on every user.
• The device list is empty for a user who is demonstrably signed in and working.
• The count of older, unlistable sessions is large or growing.
• A user reports being signed out without anyone having done it, and the audit trail shows no revocation.