Skip to main content
Free plan Three things help you notice and cut off a sign-in you did not expect. Sessions lists every browser your account is signed in on and lets you end them. Idle sign-out lets an org admin end sessions nobody is using. Security alerts email you when something changes on your account, with a button that signs everything out. They sit beside two-step sign-in, which protects the sign-in itself.

​
See and end your sessions

Open Account and find Sessions. Each row is a browser your account is signed in on, with:
  • the device, such as Firefox on Linux, read from the browser’s header;
  • the address it signed in from;
  • when it was last used and when it was opened;
  • how it was verified: authenticator app, passkey, recovery code or identity provider.
The session you are using is marked and listed first.
  • Sign out ends one session and every page it has open.
  • End all other sessions keeps the one you are using, ends the rest and tells you how many it ended. Changing your password does the same, and so does removing your last second step.
  • Both are refused while a support administrator is viewing the page as you, and neither can reach another person’s sessions. A support administrator viewing as you is shown no sessions.
  • A session opened before this feature shows as Unknown device with no address, and its last use is the day it was opened until it is used again.
What is stored: the browser’s User-Agent header (cleaned and cut to 512 characters), the address, when the session was opened and when it was last used. They are shown on your own Account page and to nobody else. Signing the session out deletes them, and a session older than 60 days is deleted by a daily job.

​
Idle sign-out

An org admin can end sessions that sit unused. Open Settings, Security and set Idle sign-out to a number of minutes from 5 to 43200 (30 days). Leave it empty for no limit. A child organization follows the stricter of its own limit and its parent’s.
  • The strictest limit among your organizations applies wherever you work. One session reaches every organization you belong to, so a person who is a member of any organization with a limit is signed out after that idle time, whichever organization the page is for. Time spent in an organization with no limit does not make it possible to reach one that has a limit.
  • What counts as use. The owner loading a page or clicking in an open page, including the small panels inside a page such as secret notes, the Explore drawers and tag fields. A page that reconnects by itself after the network dropped or after a release is not use, and neither is visiting a public page or a page that signs you out, so an idle session cannot be kept alive that way.
  • The timing is approximate. Use is written at most once a minute per session, so the sign-out comes when the session has been unused for the limit plus up to one minute.
  • What you see. The first request after the limit signs the session out and sends the person to the sign-in page with “You were signed out after N minutes of inactivity.”, then to the page they wanted after they sign in again. A page left open and untouched is signed out when the limit ends, without a request. The remember-me cookie opens nothing, because the session behind it is gone.
  • Changing the limit drops members’ open pages so each is judged against the new value.
  • The check comes first. A session past its limit is signed out instead of being asked for a code in the Confirm it is you dialog. Answering that dialog is not use of the session, and neither is passing a second step at the sign-in challenge.
Not covered:
  • Guests are not signed out by the limit, because they are not members. A guest is the least trusted person an organization has, so this is a known gap. Guests have their own end date.
  • A support administrator viewing as a customer is not signed out by it.
  • API keys, MCP tokens and mobile tokens are not sessions and are not affected.

​
Security alerts

SRE Agent emails you when something happens on your account that you may not have done. Each email says what happened, when (UTC), from which browser and network when they are known, and has two links: This was me, which opens the Sessions card on your Account page, and This was not me. These emails go to the address on the account only, ignore the opt-out for notification email, and cannot be turned off. They never contain your password, a code or a key.

​
Send alerts to Slack

On Account, under Security alerts, Send security alerts to Slack is off by default. Switched on, the new sign-in, authenticator, recovery code and lock alerts also arrive as a Slack direct message. Password and key, token or mobile sign-in alerts are email only.
  • The message goes through the first of your organizations, your home organization first, whose Slack workspace is connected and where your Slack link counts.
  • It names the browser and links to your sessions. It never carries the This was not me link.

​
Known devices

SRE Agent recognises a browser by a random value kept in a signed cookie (_sre_device). It lasts a year, is sent only to SRE Agent, and stays in your browser when you sign out. It is written, and an alert is considered, only when a sign-in is complete. A password with the second step still pending records nothing and sends nothing, so someone who has only your password cannot make this feature email you.
  • A sign-in from a browser that cleared its cookies does not alert when it is the same browser, the same system and the same network (the /24 of an IPv4 address or the /48 of an IPv6 one) as a device you already have.
  • Your first ever sign-in, and your first one after this feature shipped, record the browser without an email, because there is nothing to compare with.
  • Account, Known devices lists each device with its browser, system, network and when it was first and last seen. Forget this device removes one, so the next sign-in from it alerts again.
  • At most 20 devices are kept per person, and the least recently seen go first. A device not seen for a year is deleted by a daily job.
  • Only the browser name, the system name, the network and two times are stored. The User-Agent header, the cookie value (only a scrambled form of it) and the full address are not.

​
How many alerts you can get

So that nobody can use this to flood you with email, each kind of alert is sent at most once an hour per person. A removed authenticator is allowed once every 10 minutes, and key, token and mobile sign-in alerts are allowed once an hour for each kind. A person gets at most 10 security emails a day. Over that cap the email is dropped and one audit entry records it for the day. The change the dropped email described still happened.

​
This was not me

The link opens a page with one button, so a mail scanner that fetches the link spends nothing. Pressing it, once:
  • signs out every browser session you have, with their open pages;
  • ends every mobile app sign-in and any mobile code not yet used, and deletes your personal API tokens;
  • cancels any sign-in link or password reset link still outstanding;
  • emails the address on the account a new link for choosing a password;
  • records the report in Audit Logs.
What it does not do:
  • It signs nobody in. It grants nothing.
  • It does not undo the change the email described, such as a removed authenticator or a changed password.
  • It does not revoke organization API keys. They belong to the organization, not to you.
  • Your current password keeps working until you choose a new one, so use the emailed link soon.
The link is good for 7 days and works once. A link that is unknown, expired, already used or for an address the account no longer has reads the same neutral page. Someone who got hold of the link could only sign you out and cause one reset email.

​
What is recorded

Each event records who and which organization, and never a secret, code or hash.