Sessions and session ids

On the web, the recorder files the recording under the session id that your analytics SDK already uses. On iOS and Android, PostHog's SDK sends the events and the recording under the same session id, with no recorder (Mobile apps).

On a Mixpanel site, sessions come from the web recorder, or from a $session_id super property that you register yourself.

Source	Session id stored	If the SDK has none
Sequential SDK	Its own id, on every event	—
PostHog (web and mobile)	PostHog's $session_id	On the web, the recorder's id, which the recorder registers with PostHog. None on mobile
Amplitude	Amplitude's session_id, stored as text	None. The recorder does not register its id with Amplitude
Mixpanel	$session_id. Mixpanel's browser SDK does not set it by default	The recorder's id, which the recorder registers as a super property
Pendo	Pendo's session id	The recorder's id, sent as visitor metadata
Smartlook compatibility script	The script's own id	—

Your SDK decides when a session ends and a new id starts.

Source	When a new session starts
Sequential SDK	On the first event after 30 minutes with no event, 24 hours after the session started, or when you call sequential.reset(). Each browser tab keeps its own session. The recorder follows each change within a second.
Smartlook compatibility script	After 30 minutes with no event.
PostHog, Amplitude and Pendo	Their own rules. The recorder follows each change within a second.
Mixpanel	The $session_id super property. If you do not register your own, the session uses the recorder's id. Then a tab that stays open all day is one session.
An id that the recorder created	No idle limit. The id lasts as long as the tab.

1. The recorder loads the recording settings of your project first. If recording is off for the project, or the page is excluded, the recorder stops and sets no id.
2. For up to 2 seconds, it looks for a session id from PostHog, Amplitude, Mixpanel, Pendo, the Smartlook script or the Sequential SDK, in that order. It takes the first id it finds. The Sequential SDK stores its id in the storage of the browser tab before it starts the recorder, so the two start on the same id.
3. If it finds none, it reuses the session id in the storage of the browser tab.
4. If there is still no id, the recorder creates one. It registers the id with PostHog, Mixpanel and Pendo, so their events carry it from then on.
5. While it records, the recorder checks every second if the PostHog, Amplitude, Mixpanel, Pendo, Smartlook or Sequential SDK id has changed. If it has, the recorder closes the recording under the old id and continues under the new id. The part under the old id keeps the user id that it had before the change, also after a reset() at sign-out.

The recorder takes the id of the Sequential SDK only if no other analytics SDK on the page gives one. If PostHog, Amplitude, Pendo, the Smartlook script or a Mixpanel $session_id is also there, the recorder takes that id. Then the events of the Sequential SDK do not join the recording.

For example, this can happen during a migration.

Each browser tab has one sampling decision per session id. So in one tab, a visit never has some pages kept and others dropped.

• A session that spans several tabs is sampled in each tab separately.
• If the browser blocks storage, every page load is sampled separately.
• A session that sampling leaves out still gets its id. It has no recording.

A recorded session can also stop early:

• Each page load stops recording after the Max minutes of the project.
• Sequential stops accepting the recording of a session when it reaches Max MB.
• Both are under Session caps in Recording settings. The defaults are 60 minutes and 25 MB.
• If a single-page app moves to an excluded page, recording stops until the next page load.

• Mixpanel in a browser where the recorder has never registered an id. For example: no recorder, recording off, only excluded pages visited, or events sent on a first visit before the recorder registers its id.
• Events that your backend sends through a server-side SDK or API, unless you pass the session id of the visitor with each event.
• Profile-only updates that some SDKs send outside a session, such as calls to Amplitude's Identify API.

Mixpanel after the recorder has run

Mixpanel keeps the id that the recorder registers as a super property. All tabs of your site share this id. Mixpanel keeps it across visits. So after the recorder has run in a browser, the Mixpanel events that it does not cover still have a session id.

These events carry the id that the recorder registered most recently, so they go into that older session:

• events sent while the recorder starts in a new tab
• events on excluded pages
• events after you turn recording off

Amplitude session_id of -1

Amplitude uses a session_id of -1 to mark events outside a session. Sequential does not treat these events as events without a session. It stores -1 like any other id.

• All such events, from all users, form one session on Latest, with the session id -1.
• Unlike events without a session id, this is a session. Sequential can judge it, and Ask can return it.
• If you send Amplitude events yourself, do not send session_id at all. Do not send -1.

1. Register a $session_id super property with Mixpanel.
2. Change it when a visit ends. The recorder finds the change.

Use an id of at most 128 characters. Use only letters, digits, dots, underscores, colons or hyphens. A UUID works. Sequential refuses recordings under any other id, so the session has events but no replay.

If a new recording of the same user starts in 30 minutes or less after the previous one ends, the replay links them. The Info tab shows ← previous segment.

This needs a user id on the recording:

• On the web, the recorder reads it from PostHog, Amplitude, Mixpanel, Pendo or the Sequential SDK.
• In iOS and Android apps, it comes from PostHog.
• On a site that uses only the Smartlook compatibility script, recordings have no user id. So the replay never links them.

Background judging reads events, so it does not need a recording. For what Ask and the Insights tab need, see below and Judgments.

Events that count for judging

Events that are not System events are page views, clicks, form submits, identifies, errors, rage and dead clicks, or custom events (Events).

When the judgment arrives

Sequential looks for sessions to judge every 5 minutes. So the earliest judgment arrives 30–35 minutes after the last event. It takes longer in these cases:

• Many sessions are waiting. Each check picks up at most 500 sessions per project.
• Your project has used its daily judging allowance. Then sessions wait until it resets at midnight UTC.

Sessions marked too short

Some sessions have 3 or more events, but fewer than 3 that are not System events. After 30 minutes with no new event, Sequential marks such a session too short. It never judges the session, even if more events arrive later under the same id.

Ask and Insights

• Ask looks only at sessions with a session id and at least 3 events of any kind. Of those in your date range and filters, it takes the newest 2,000.
• The Insights tab needs a recording and at least 3 meaningful events. If not, it shows "Not enough activity to judge — fewer than 3 meaningful events".

1. To see the events of a session on the Events page, open the ⋯ menu of its row on Latest. Then choose Open events.
2. Play a session. The Info tab shows the Session id.
3. Check the Events tab of the replay. It lists the events that your SDK sent from 5 minutes before the recording starts to 5 minutes after it ends. It shows at most the first 2,000.

The Sequential SDK starts a new session after 30 idle minutes, after 24 hours, or when you call sequential.reset(). For example, you can call it at log-out. If this happens while a page stays open, the recorder follows the new id within a second.

A row on Latest shows:

• Who: the label of the latest User ID in the session. With the Sequential SDK, PostHog or Mixpanel, an anonymous id that is linked to an identified value shows as that value. See Users and identity.
• What happened: the route of the first page view, then how many different routes the session viewed, such as /pricing → 6 pages. Below it is the verdict of background judging, or "Not judged yet".
• Problems: JS errors and failed requests, such as "2 JS errors". They count the whole session in your date range, whatever your filters.
• Duration, and When the session started, such as "3 h ago". Hover When for the exact local time.

The list shows no session id. The ⋯ menu of a row has Copy session ID, Copy user ID, Show only this user and Open events.

What happened, Duration and When count only the events in your date range. From 9 October 2026, a filter decides which sessions are listed, not which of their events count. Duration is the time from the first event to the last. So if a session crosses the edge of the range, the row shows only the part in the range.