What this task actually involves
Revoking an old GitLab session looks like a single click, but it is really a review task with two separate effects. One effect is limited to the session you select. The other reaches beyond that session and ends remembered-login tokens everywhere. Understanding both before you click keeps you from locking yourself out or from assuming more was cleaned up than actually was.
This guide covers only the owner’s own session list. It does not cover server administration, Rails console commands, or changes to anyone else’s account.
Step 1: Reach the session list and read it before acting
A GitLab owner can open Edit profile, Access, Active sessions and revoke an unwanted session.
A GitLab owner can open Edit profile, Access, Active sessions and revoke an unwanted session. Source
Before revoking anything, treat the list as something to read, not just something to clear. For each entry, note what you can actually see: the device or browser description, when the session was last active, and whether you recognize it as yours. A session you do not recognize is a reason to look more closely, not automatic proof that someone else has your password. Shared computers, older phones, and browsers you no longer use can all produce entries that look unfamiliar.
A practical order is:
- Identify the session you are using right now, so you know which entry must stay.
- Mark entries you cannot account for.
- Decide whether the problem is one stale session or a broader concern about remembered logins.
- Only then revoke.
Step 2: Know what the current session does not do
The current active session is not revoked through that action.
The current active session is not revoked through that action. Source
This is the detail most likely to cause confusion. Revoking an old session does not sign you out of the browser you are working in. That is convenient, because it means the cleanup action does not interrupt the review itself. It also means that if your goal is to end the session you are currently using, revoking another entry will not accomplish it. Signing out of the current session is a separate action from revoking a listed one.
Step 3: Account for the wider remembered-login effect
Revoking any session also revokes Remember me tokens across devices.
Revoking any session also revokes Remember me tokens across devices. Source
This is the part that changes the scope of the task. You may intend to remove one old entry, but the effect on remembered logins is broader than that single entry. If other devices rely on remembered logins, expect those remembered logins to end, and plan for signing in again on those devices with credentials you still control.
That planning step matters. Before revoking, confirm you can still sign in through a method you control, such as your password or another recovery path already set up on the account. Do not remove or replace your recovery method as part of this cleanup. Keep it in place until you have confirmed the account is in the state you want.
Decision table: one session or a wider remembered-login reset
| What you observed | What revoking does | What to plan for |
|---|---|---|
| One stale session you recognize as an old device of yours | Ends that session; the current session stays active; Remember me tokens end across devices | Sign in again on any device that was relying on a remembered login |
| A session you cannot account for | Same as above | Treat it as a prompt to review your sign-in security, not as proof of a breach |
| You want to end the session you are using now | Revoking a listed session does not do this | Sign out of the current session separately |
| Several unfamiliar entries | Each revocation carries the same wider remembered-login effect | Decide whether repeated revocations are needed, and keep your recovery path intact |
Step 4: Verify the result honestly
The session list is the place to confirm what changed. Check that the entry you targeted is gone and that the session you are using is still present. Then check the devices you expected to be affected by the remembered-login change and sign in again where needed.
Be careful about what the list can and cannot tell you. An entry disappearing from the list shows that the session was revoked. It does not, by itself, tell you why the session existed, who used it, or whether anything else on the account changed. If you revoked a session because you did not recognize it, the sensible follow-up is to review your sign-in security rather than to assume the matter is closed.
Common failure paths
- Revoking the session you are working in by mistake. The current session is not revoked through that action, so this specific mistake is not what happens; but signing out separately will interrupt your review. Finish the review before signing out.
- Assuming one revocation cleaned up every device. The remembered-login effect is wider than the single session, but the session list is still not a complete picture of every place you have ever signed in.
- Removing your recovery method too early. Keep a recovery path you control until you have confirmed the account is in the state you want.
- Treating an unfamiliar entry as proven intrusion. It is a lead for further review, not a conclusion.
A useful next task
GitLab sessions are one account. If your concern is broader, the same discipline of separating a session from a person applies elsewhere. The guide on reviewing Google account devices without mistaking sessions for people walks through that distinction for a different account, and it is a natural follow-up once you have finished here.
If part of your concern is what a username is attached to publicly, a username lookup can show public matches as leads. TraceSeek covers 3,000+ platforms, and the first scan is free and takes 20-30 seconds. Public matches are leads, not proof of ownership, and a username search is not a complete account inventory.