Limits and defaults

If the server value for a judging allowance or a request limit is 0, empty or not valid, Sequential uses the default. So nobody can turn off these limits by mistake.

Uploads

• One upload from a website: recording starts again on the next page load. The likeliest cause is a very large page snapshot, which the recorder sends in one upload.
• One upload from a mobile app: PostHog's mobile SDK decides what the app does next.
• Upload volume per project: all the project's visitors share it. The web recorder keeps up to 5 refused uploads and sends them again after 30 seconds. After 5, it drops the oldest, so a long overload leaves gaps in the replay.
• Upload volume per network address: everyone behind that address shares it, whichever project they visit. The web recorder sends refused uploads again, as for the per-project limit. Visitors behind one office network count together.

Per session

• Max MB: Sequential refuses more uploads for the session, from websites and mobile apps. On websites, the recorder stops. If Sequential's counter is unavailable, it does not apply the limit. The count starts again when a session sends nothing for 2 hours.
• Max minutes: because it counts from each page load, it limits each page, not the whole session.
• Skip sessions under (ms): on websites it counts from each page load. If a visitor leaves a page sooner, the recorder sends nothing for that page.
• How long you can play a replay: the Session replay tab's summary line shows it as "30 d", and a line under it says "Replays kept · Set by Sequential: 30 days". The organisation sets it for all its projects. Only Sequential support can change it. A shorter period deletes nothing: stored recordings keep their old period. Through the settings API, a change of replay_retention_days gets 409 retention_set_by_organisation and saves nothing. See Retention and deletion.

DevTools

• Per page: at 1 MB, DevTools capture stops for the rest of the page. At 1,000 network requests, network capture stops for the rest of the page.
• One DevTools entry: 64 KB. Sequential does not record a larger entry.
• Sequential counts bursts of uncaught errors separately from console messages.

1. Open your browser's developer tools.
2. Open Network.
3. Look at requests to /rec/.

• A 413 means an upload was too large or the session reached Max MB. In the second case the response says session_cap.
• A 429 means the page reached an upload budget.

See Check your install.

• Sequential picks the sample from the session id, so a session is in or out on every page.
• The recorder gets the share rounded up to 1, 1/2, 1/4 and so on, so that its settings do not reveal your traffic. So the recorder can collect for up to about twice as many sessions as Sequential keeps. Sequential drops the rest when they arrive.
• A session outside the rounded-up share installs no listeners.
• A new project with no recorded days keeps every session.
• Until Sequential has worked out a project's share, for example just after a server starts, it collects no heatmap data for that project.
• If Sequential cannot check the daily limits, it stores no heatmap data until it can. Recordings are not affected.
• With heatmap data on, the recorder that each page loads is about 7.6 KB larger, compressed: about 22 % more, measured with DevTools off. This is on every page load, in the sample or not.
• A heatmap page picture over 4 MB, compressed, is not kept. Sequential answers too_large for that page. Sequential also answers too_large when the builder refuses a part of the recording: it would use too much memory, it is too dense to read safely, or two earlier attempts on it did not finish. Sequential keeps a too_large answer for one hour, and starts no new build for that picture during the hour. Only the builder service builds pictures. A finished picture is kept for at most 15 minutes. See The page picture.

• The 1 MB JSON limit includes the last batch a page sends as it closes. If Sequential refuses a JSON request, it stores none of that request's events.
• Sending from your own servers: examples of clients refused as bot traffic are curl, axios, node-fetch and python-requests.
• Headless browsers: automated tests in a headless browser do not appear.
• A retried request: an SDK sends a request again when it gets a server error or no answer. Sequential drops the retry as a duplicate only if every event in the request carries the SDK's own event id: uuid from PostHog and the Sequential SDK, $insert_id from Mixpanel, insert_id from Amplitude. If one event has no id, Sequential stores all the events in the retry again.
• Sequential does not drop duplicates from the Smartlook shim or Pendo. It also does not drop duplicate runtime issues: the problems that it takes from replay uploads to build findings.
• Sequential compares a retry with the whole earlier request. If an SDK sends the earlier events together with new events, Sequential stores the earlier events again.
• A retry that arrives in a new week is stored again. Weeks start on Monday at 00:00 UTC.
• Sequential remembers about the last 100,000 requests that carry event ids, across all projects on the server. A retry that arrives after that is stored again.
• A self-hosted server whose database was created before this feature drops duplicates only after it applies migrations/2026-09-28-async-dedup-window.sql. Until then, it stores every retry again.
• The event rate limit counts per project, not per key. A new key does not reset it. It counts the events from sequential.js, PostHog, Mixpanel, Amplitude, Pendo and Smartlook. Session replay has its own limit: see Session replay.
• Each minute starts at 00 seconds on the clock. At the start of a minute, the project can send its full 20,000 events again.
• If a batch goes over the limit, Sequential refuses the full batch. It does not store a part of it. The refused events still count for that minute.
• The answer is 429 with the body { "error": "rate_limited", "retry_after_sec": N } and a Retry-After header. N is the number of seconds to the end of the minute. Pendo gets its image with the 429.
• These requests do not count: a batch with no events, and a request that Sequential refused because the website is not in the project's allowed origins.
• The Sequential SDK on a 429: it waits retry_after_sec. If there is none, it waits the Retry-After value. If there is none, it waits 60 seconds. The wait is 1 second at minimum and 300 seconds at maximum. During the wait, it keeps the refused batch and the events that it records. It keeps at most 100 events and about 128 KB, and drops the oldest first. After the wait, it sends them. It sends a refused batch again only once. If the page closes during the wait, the SDK sends what it keeps as the page closes.
• Other SDKs follow their own rules for a 429.
• A refused batch shows in the project's refused data as event_rate_limited. See Troubleshooting.
• If the store that counts the limit is unavailable, Sequential accepts the events.
• See Sessions.

When a Sequential server has too much work, it refuses some uploads at once, before it reads them. Then it can answer the other uploads quickly, and fewer requests time out. This protects the server. It is not a limit of your project: Sequential does not read the project or the key before it refuses.

• The answer is 503 with the body { "error": "overloaded", "retry_after_sec": N } and a Retry-After header. N is a random number of seconds from 3 to 8, so that clients do not all send again at the same time. Sequential stores nothing from that request.
• Only uploads are refused: events from the Sequential SDK, PostHog, Mixpanel, Amplitude, Pendo and Smartlook, and recording uploads. The app, the API, sign-in, agents and the loading of the SDK and the recorder are never refused.
• Sequential refuses a part of the uploads. The part becomes larger while requests wait too long in the server, or while the server is too busy, at most 95%. It becomes smaller when the server is calm again: quickly when the server is less than 70% busy, and slowly from 70% to 80%, so that the part does not go up and down. When the server already handles 128 uploads, it refuses each new one until one of them is done.
• From 13 October 2026, how busy the server is counts only when it stays more than 90% busy for 1 second, and only while the server gets about 200 uploads a second or more. So other work on the server, for example a background job, does not make Sequential refuse uploads. At 97% busy or more, the part becomes larger more quickly.
• Measured on a test box, not a promise: one server with half a CPU core, at 3,200 events a second. Sequential refused about 46% of the uploads, answered the other uploads in 160 ms or less (p95), and no request timed out. With no refusals, the same load had a p95 of 23.5 seconds, and about 20% of the requests timed out. A sudden start at 1,600 events a second refused about 2% to 4% of the uploads, nearly all in the first few seconds.
• The Sequential SDK on a 503 overloaded: it waits as on a 429. It waits retry_after_sec, else the Retry-After value, else 60 seconds, from 1 to 300 seconds. It keeps the batch and the new events, at most 100, and sends a refused batch again once. On another 503, it tries again quickly, 3 times in total.
• The recorder keeps the upload and sends it again after about 30 seconds. See Replay limits in detail.
• Other SDKs follow their own rules. If a server stored a batch after the SDK stopped waiting, and the SDK then sends the batch again, Sequential stores it once when every event carries the SDK's own event id. See A retried request in Event limits in detail.
• These refusals do not show in the project's refused data, because Sequential does not know the project at that time.
• On a self-hosted server: GET / shows ingest.shed, ingest.shed_fraction, ingest.event_loop_lag_p99_ms, ingest.sojourn_p95_ms, ingest.in_flight and ingest.utilization. ingest.shed_raised_by and ingest.shed_raised_far count which signal made the part larger (utilization, sojourn or lag), and ingest.shed_by_cap counts the uploads refused at 128. INGEST_SHED=off turns it off.
• How busy the server is (ingest.utilization): the larger of the event loop's busy time and the process CPU divided by the CPU quota. INGEST_CPU_QUOTA_CORES sets the quota in cores. Without it, Sequential reads the quota from the cgroup files, else it uses 1 core. The limits are INGEST_SHED_UTIL_HIGH (0.90), INGEST_SHED_UTIL_FAR (0.97), INGEST_SHED_UTIL_LOW (0.80), INGEST_SHED_UTIL_FAST_LOW (0.70), INGEST_SHED_UTIL_TICKS (4 checks of 250 ms) and INGEST_SHED_UTIL_MIN_ARRIVALS (50 uploads in a check).

• Individual user actions: older events in the range are not listed.
• Sessions → Latest: each page holds 100 sessions. With JS errors and With failed requests apply before Sequential splits the list into pages, so they search the whole range.
• Users and Accounts: see Users and accounts.
• Past filters: the last 10 different filters that you applied on that page, in that project. Sequential removes older entries.
• Breakdowns: with two levels the limit counts pairs. That is why a first-level total can be too low.
• Blank ids: Events, Users, Accounts and Sessions never count a blank id as a user, an account or a session. Funnels, Flows and Retention never count an event without a user id as a user.

• The Insights tab in the replay player judges one session on demand.
• A session with fewer than 3 events that are not System events: Watch counts it as not judged. The Insights tab says "Not enough activity to judge — fewer than 3 meaningful events".
• Sessions taken per check: 500 per project. The rest wait for the next check.
• Events the judge reads: lower-priority events are, for example, custom events and plain clicks. A judgment made from fewer events ranks like a full one.

• Background judging starts again after midnight UTC.
• Ask in the app: if Sequential cannot read the allowance, it refuses the search. The server answers 503 budget_unavailable, "Ask is unavailable right now. Try again shortly.", with Retry-After: 30. It spends nothing. This is not the same as 503 ask_unavailable, which means that judging is not set up. A saved answer still returns.
• Operators change the Ask allowance with ASK_DAILY_TOKENS and the background judging allowance with BELIEFS_DAILY_TOKENS.
• Try it: find it under Settings → Projects → your project → Insights.
• The Insights tab: Sequential refuses new judgments until midnight UTC. The tab also says when the allowance resets.
• The Insights tab and Try it: if Sequential cannot read the allowance, they do not judge. The server answers 503 budget_unavailable with Retry-After: 30. Sequential spends nothing and does not call the judge. The Insights tab shows "Insights failed (Insights can't run right now. Try again shortly.)". Try it shows "Preview failed" and "Can't test the rubric right now. Try again shortly.". Both show Retry.
• The allowance of the Insights tab also pays for the screening of fix briefs and for the key actions that the judge picks for Dashboard.
• If Sequential cannot read the allowance, the screening of fix briefs and the key actions for Dashboard continue, with a cap. Each server process allows, per project, 10 brief screenings a minute and 5 key-action judgments a minute. With more than one server process, each process has its own cap.
• Past the screening cap, Sequential does not screen the brief. It withholds every quoted passage, and the brief says "screen paused". Sequential does not keep this result, so a later request screens as usual. See Privacy at a glance.
• Past the key-action cap, a new dashboard starts with Most frequent events instead of Key actions, and without Failed or abandoned. The dashboard keeps these tiles. An add of Key actions says "Key actions can't be worked out right now. Try again later." An add of Failed or abandoned says "Failed and abandoned events can't be worked out right now. Try again later."

• Events the Insights tab judges: clicks and page changes read from the recording still come from the whole session.
• Re-run: within 10 minutes of a Re-run, the tab says "Already judged — same events, same questions, so the verdict below is unchanged."
• Waiting in the browser: Retry can return a judgment that the server finished in the meantime.

Why re-judging is limited

Sequential limits re-judging on purpose. Every new judgment is a new call to the judge. So Sequential reuses saved judgments.

• Daily allowance: Ask in the app has its own. See Daily allowances. When it is used up: "Today's judgment budget is used up · resets …"
• Ask does not show sessions that the judge rated below its cut-off.
• Sessions considered: each needs a session id and at least 3 events. The footer, "Searched the N most relevant of M sessions", counts only these, so M is never more than 2,000. An M of 2,000 means Sequential left out older sessions.
• Sessions judged per run: each click on Search N more is a new run on the daily allowance.
• Sessions judged together: Sequential judges up to 8 at a time. The footer adds "· some sessions could not be judged" if Sequential cannot judge a group.
• Waiting in the browser: after "Ask failed", Retry can return the saved answer of the run that finished.

• Sequential checks the allowance of the token first, then the allowance of the project.
• Sequential estimates the tokens of each group of up to 8 sessions before the judge reads it. If the next group does not fit in an allowance, Sequential does not send it. So Sequential can refuse a call before an allowance is fully used. The estimate can also be low, for example for sessions with many ids. Then a call can take an allowance a little over its limit. Sequential charges what the judge actually used.
• If an allowance runs out after the judge has read some sessions, the call does not fail. The answer has stopped: "budget", a stop_reason and a next_cursor. The answer keeps the matches from the sessions that the judge read. Sequential charges only what it spent. Sequential does not save an answer that stopped.
• The limits on calls at the same time count per server process, not across servers. A call holds its place from its first paid judgment to when it ends. With more servers, more calls can run at the same time.
• A saved answer uses none of the agent allowance. But Sequential first checks that the project and the token still have agent allowance left, before it reads anything. If one is used up, or Sequential cannot read the allowances, the call is refused, also when a saved answer exists. A saved answer holds no concurrency slot, so it cannot get 429 ai_concurrency. Screening its labels can still use the allowance for screening visitor text. The app and an agent share saved answers: the same question over the same sessions returns the saved answer.
• Screening the answer uses the allowance for screening visitor text. See Daily allowances.
• Operators change the limits with AGENT_DAILY_TOKENS, AGENT_TOKEN_DAILY_TOKENS, AGENT_JUDGE_MAX_CONCURRENT and AGENT_JUDGE_MAX_CONCURRENT_PER_PROJECT.
• For each refusal, see Troubleshooting.

Sequential sizes the read limit so that a person who works normally does not reach it. If the store that counts the read limit is unavailable, Sequential lifts the limit, so pages keep working.

The "running at once" limits do not depend on that store.

• Sequential limits how often each action can be tried from one network address, to slow down guessing. The limits count per address, not per person.
• Join the waitlist: over the limit, the form says "Too many attempts. Wait a few minutes and try again."
• Ten wrong codes in a row count across sign-ins. A correct code resets the count.

• A request with a person's signed-in session gets exactly that person's access.
• Find the Ingest keys under Settings → Projects → your project → Sources & keys.
• Ingest keys go in your pages and apps, so treat them as public. They can send data and get the project's recording settings.

• The table lists all 33 agent tools.
• A finding's sessions list needs findings:read, on REST and on MCP. sessions:read does not allow it.
• In a finding's sessions list, and in the samples of a finding's evidence (GET /api/findings/:n and the get_finding tool), each session has replay_state and replay_ready_by next to has_replay. replay_state is ready, processing, expired or none. replay_ready_by is the time when a processing recording will be ready, else null. The two fields can be absent, for example when Sequential cannot read the state within its time limit. Then use has_replay, which only tells if Sequential has an index of a recording.
• From 14 October 2026, for a dead end, each sample in samples also has returned: back, app or unknown, how the visitor came back. A sample without a kind has no returned. Each finding in the list and in get_finding has returns: { back, app, unknown }, the dead end's sessions by how the visitor came back. It is null for the other kinds, and for a dead end found before the counts existed.
• For a token, each session_id in these lists comes as {"id": "…", "source": "observed"}, and a release name in a finding's sessions list comes as {"withheld": "not screened"}. See Privacy at a glance.
• With a token, GET /api/projects/:id/rubric and /rubric/history give the answer of the get_rubric tool, screened. :id must be the token's project, else the answer is 404. The history gives at most 20 changes and never who made them. Changing or resetting the rubric, and Try it, need a person's signed-in session.
• GET /api/releases does not accept a token.
• POST /api/findings/:n/verdict accepts only a person's signed-in session. So does DELETE /api/findings/:n/links/:id, which removes a link.
• An agent calls a tool through MCP, or with POST /api/agent/<tool> and the tool's arguments as a JSON object. The two give the same data. With a token, GET /api/findings/:n/verification runs the get_verification tool and gives the same answer too. It counts once toward the project read limit. If a limit refuses it, the answer keeps the status and the Retry-After of that limit. For a tool outside the token's scopes, REST answers 403 insufficient_scope, and MCP answers "Tool not available for this token".
• The MCP endpoint is /mcp. The endpoint /mcp/readonly never lists record_release or link_fix. It lists ask_sessions, so a read-only connection with an ask:use token can spend the agent allowance. POST /api/agent/record_release has no read-only form: it works with releases:write.
• The MCP server name is sequential.
• A token cannot create, list or revoke tokens. These actions need a signed-in owner or admin.

• GET /api/projects/:id/agent-activity shows how the access tokens of a project used the agent tools. The Agents page in the app shows it under "Activity, last 7 days". For each token, it shows the calls, the removed and withheld counts and the last call. The page explains the two counts: "Removed: text our screen flagged and took out. Withheld: text we sent back unread because we couldn't check it." If no agent called in the 7 days, it shows "No agent calls in the last 7 days." Under Recent calls, it shows the newest 50 calls. If Sequential cannot read the log, the page shows "Activity isn't available right now."
• It needs the signed-in session of an owner or admin. It does not accept an access token.
• days: 1–30. The default is 7. Any other value gets 400 bad_request: "days: an integer 1-30".
• The answer has window_days, state, per_token, recent, tokens and tokens_state.
• per_token has one row for each token that has calls in the window. The token with the most calls is first. Each row has token_id, calls, removed, withheld, input_tokens and last_call_at.
• recent has the newest 50 calls, newest first. Each call has tool, token_id, consumer (mcp or rest), observed, removed, withheld, input_tokens and delivered_at.
• observed is the number of different observed text values in the answer. removed is the number that the screen removed. withheld is the number that Sequential withheld for another reason, for example because it could not screen them. input_tokens is the paid AI input tokens of the call: the screen, and the judging of ask_sessions. In per_token, the counts are totals.
• Times are in UTC, in ISO 8601 format.
• The answer counts only the calls that the agent call log records. These are the successful calls of every agent tool except record_release. A token's GET /api/findings/:n/verification runs get_verification, so it is counted too. The answer does not count record_release, a call that failed, or the REST routes GET /api/findings and /api/findings/:n.
• Sequential writes the log on a best-effort basis. A missing call does not prove that the call did not occur.
• state is ok or not_measured. not_measured means that Sequential could not read the log, for example because the read took more than 10 seconds. Then both lists and tokens are empty, and tokens_state is unavailable. Empty lists with not_measured do not mean zero calls. The status is still 200.
• tokens gives a name for the token ids in per_token and recent. Each entry has id, name, kind and identified_as. name is the name that the token got when it was created. A revoked token keeps its name. kind is pat for the tokens that you create, and oauth for a claude.ai connection. identified_as is the name that the agent's MCP client sent, at most 60 characters, or null. Sequential does not check it.
• tokens_state is ok or unavailable. ok means that the name lookup succeeded, or that there were no token ids to look up. unavailable means that Sequential could not look up the names, or could not read the log. Then tokens is empty. An empty tokens with unavailable does not mean that the tokens have no names.

• list_watch: the sessions that Watch ranks highest, and the sessions that the judge was unsure about. days: 1–30, default 7. limit: 1–100, default 25, for the two lists together. The unsure list gets at most a quarter of limit. Each row has a severity: broke, struggled or minor, the Watch group of the session (Watch). null means the session is not judged.
• list_sessions: the sessions with the most recent activity first, by the time of the last event of each session, not its start. The same days and limit. With judged_only: true, only judged sessions.
• Rows and counts. From 10 October 2026, each row of list_watch and list_sessions gives last_page: the page that the session ended on, not the page where a signal happened. Before, this field was path. Each answer also gives sessions_total, and list_watch gives unsure_total: how many sessions match in the whole window, or null when Sequential cannot count them in time. truncated is true when the answer leaves out sessions. Then narrow days, user_id or belief_filters. beliefs_meta counts every session in the window, before belief_filters and judged_only.
• From 10 October 2026:
  • A compact row's judgment also has struggling: true when the friction is at the middle of the friction scale or higher. This is the same rule as in get_struggle_by_segment.
  • list_watch takes platform_os: only the sessions with an event on that operating system, with the name that a row shows. From 12 October 2026, the case of the name does not matter: android and Android match. get_struggle_by_segment by platform_os also puts both in one group, Android.
  • From 12 October 2026, the filters and breakdowns of an agent also take platform: web, ios, android or other. It tells the website from the app. Safari on an iPhone is web, and the iOS app is ios. An app view that shows a web page also counts as web. A platform filter takes only these four values. Sequential refuses any other value. There is no device filter. For devices, use get_struggle_by_segment by device.
  • From 15 October 2026, the filters and breakdowns of an agent also take traffic_source: the other site that a visit came from, as its host without www., such as google.com. A visit with no referrer, or from a page of the same site, has an empty value: direct or internal. Another domain of your project counts as another site. utm_referer still gives the full referrer address.
  • list_watch with detail: "counts" gives no rows, only counts over every session in the window and filters: judged, unjudged, struggling, need_a_look, routine and unsure. It does not use limit.
  • list_sessions takes order: "asc" for the oldest first, by the last event of each session. It cannot be used with judged_only or belief_filters.
  • A list_sessions row has ended_at, also in compact detail, and is_first_session: true when it is the first session of its person that Sequential holds, false when that person has an earlier one, null when Sequential cannot check.
• list_watch and list_sessions also take these arguments:
  • has_errors: true or has_failed_requests: true: only the sessions whose recording measured at least one JS error, or at least one failed request. A session without a recording, or without measured DevTools data, never matches. Then the answer has devtools_meta: the number of recorded sessions in the window, for the whole project, that were not measured or did not capture that kind. So an empty list does not prove that there were no errors. The value false gets a tool error. To get all sessions, leave the argument out.
  • belief_filters: up to 10 { key, min }. Only judged sessions where each value is at least min, for example friction_score or a signal. The keys are in get_rubric.
  • user_id: only the sessions of one person. An anonymous id that was identified later finds the same person.
  • detail: compact (the default) gives the top answer of each verdict, the friction label, and the signals that are on or unclear. full gives every answer with its probability and the state of every signal.
  • Two shapes: an ask_sessions result always has the full judgment. Its verdict_intent and verdict_outcome each have id, value, label, probability, confidence and options. list_watch and list_sessions give the compact shape unless you ask for full, and get_user_journey's verdict is always compact. An agent that compares sessions from these tools must read both shapes.
  • A label is a string when it comes from Sequential's default rubric. When the project edited its rubric, a label is {"observed": "…"}: text that a team member typed, after the screen. If the screen removed it, the label is {"withheld": …}. An agent must read all these forms.
  • A compact row of list_watch has no ended_at: use started_at and duration_ms. Its probabilities and attention have 2 decimals. Its devtools is "none" when the recording was measured and had nothing, or else only the counts that are not 0. A count that is not there is 0. With suppressed: true, Sequential dropped some entries, so the counts are lower bounds. full gives ended_at and every DevTools count.
• get_session_full: one session, with its judgment, its moments and its DevTools counts. If the session has a recording, each moment has a replay link.
• Pages of one session. From 10 October 2026, get_session and get_session_full give pages: up to 10 route templates, the 10 with the most events, in the order that the session first visited them. Each page has events, the number of events of every kind on it (not page views, and not time), and first_offset_ms, the time from the start of the session to its first event there. pages_total counts all the pages of the session. A page that the session visited again is listed once, so pages is not the path. For every step in order, use get_session_timeline.
• get_user_journey: from 10 October 2026, the sessions of one person in the order they started, oldest first. user_id is any id of the person: an anonymous id that later identified finds the same person. days: 1–30, default 30. It gives at most 50 sessions. With more, truncated is true and sessions_total counts all of them. Each session has first_page, last_page, pages_total, the compact judgment as verdict, overlaps_previous and is_first_session. overlaps_previous is true when the session started before an earlier session of the list ended, for example in two tabs or on two devices. identified is true when an identify call linked an anonymous id to the person. false does not mean anonymous. The tool gives ids only, never a name, an email, an IP address or a property.
• get_session_timeline: one session, event by event, in order: each page, click, form submit, custom event and error, with its time from the start of the session. From 10 October 2026, the answer also names the session's person: user_id after identity resolution, and anonymous_id, the id that the session sent, when it differs. If Sequential cannot look up the person in time, user_id comes as {"withheld": "not resolved"}. These are the events that the judge read. Sequential does not show system events, and for a long session it keeps the 255 most informative events, in order. Each event has an id, for example E001. A moment of get_session_full names the same id. limit: 1–120 events, default 60. start: 1–255, default 1. If there are more events, use next_start as start to get the next part. A session with fewer than 3 events has no timeline: timeline_state is too_short.
• Replay links. From 11 October 2026, replay_url is null when Sequential holds no recording of the session. It is also null when Sequential cannot check this in time. The tools tell the agent: "replay_url is null when Sequential holds no recording of the session." get_session_timeline has has_replay: true, false, or null when Sequential cannot check. Each session of get_user_journey has has_replay.
• list_errors: the JS errors and failed requests of the project, in groups. The group that the most sessions hit comes first. From 14 October 2026, a group's page is the page where it happened most often, the same page as its finding. Each group also has finding: { number, id, status, verdict } when Sequential holds a finding for the same problem. id is like F-12, status is open or dismissed, and verdict is the team's latest verdict (not_a_problem, wont_fix, confirmed or reopened) or null. finding is null when there is no finding, {"withheld": "needs findings:read"} for a token without that scope, and {"withheld": "not available"} when Sequential could not check. The rows of get_overview's errors.top have the same finding. days: 1–30, default 7. limit: 1–50 groups, default 20. Each group has up to 3 sample sessions. A sample has a replay link only when Sequential holds a recording of it. A group has no minimum count, so an error that is too rare to become a finding is in the list too. With session_id, it gives the errors and failed requests of that one session in time order, up to 100. Each has a replay link at that moment when Sequential holds a recording of the session. Then it reads the time of that session, not the last days days, and it refuses kind and limit. The errors come from recordings with DevTools on and from $exception events. Console messages are not included. Each sample also has user_id. From 12 October 2026, it is the person of that session, resolved as on a session row. Only when Sequential resolves no person for the session is it the id that the occurrence was stored with. users counts these people.
• get_struggle_by_segment: how the judged sessions went, in groups of one field (by): page, device, platform_os, browser or country_code. For each group, it gives the judged sessions, how many of them struggled, the average friction, the 3 most frequent signals and outcomes, and the 2 sessions with the most friction, each with a replay link when Sequential holds a recording of it. A session struggled when its friction is at the middle of the friction scale or higher: 1.5 or more on the default scale of 4 levels. A signal counts when the judge gives it 0.7 or more. With page, a session counts in each route template that it viewed, so pages overlap. device is mobile for iOS and Android, desktop for other operating systems, and unknown when there is no operating system. The other fields come from the latest event of the session. Only judged sessions count. A group with fewer than 5 judged sessions has small_sample set to true: its percentages are not rates. days: 1–30, default 7. limit: 1–50 groups, default 10, with the most judged first. min_judged: 1–1000, default 1. It reads at most 20,000 judged sessions. When it leaves out groups or sessions, truncated is true. An example session has internal: true when its person is marked internal.
• From 15 October 2026, list_heatmap_pages and get_heatmap read the counts of Heatmaps. list_heatmap_pages lists the web pages with heatmap data, up to 20 (default 10), by views or by frustration: rage bursts per 1,000 views, with pages of little data last. When every page of the window has little data, all_low_data is true. Each page has a page_ref. get_heatmap takes a page_ref or a page address, and one device class. It gives the most clicked elements, the elements that frustrate people, and scroll depth, up to 20 elements in a list (default 10). For up to 3 elements with rage clicks in the days that the Sessions list reads, the most rage clicks first, it also gives up to 5 recent sessions each, from that list. Both take days 1–90 (default 7).
  • The counts come from the sampled sessions of Heatmaps. A device class is the layout width of a web page: mobile below 768 px, tablet below 1,024 px, desktop from 1,024 px. Mobile apps have no heatmaps.
  • An element is named by its kind, its place and a path of tags and positions. Sequential withholds element text, class names, ids and the names of custom elements: an unknown tag shows as …. An agent never gets the page picture.
  • The counts include your team, and the answer says so: internal.counts_separable is false. There is no exclude_internal.
  • When heatmap data is off for the project, the answer is off with the reason. With no data in the window it is not_measured, and with no numbers.
• get_rubric: from 11 October 2026, the whole rubric as document: each question's id, kind, label, role and text, its options or levels with their criteria and phrases, and its weight. It also gives limits: the most questions, options and levels, and the longest texts, that a rubric can have. questions, the earlier short form, stays for now. With history: true, it lists the changes instead, newest first: the version, the ids that were added, removed or reworded, the time, and changed_via (staff, agent, or null for a person in the app). It never names who made a change. limit: 1–20, default 20, only with history. Sequential screens the texts of a custom rubric. See Privacy at a glance.
• get_calibration: how often the judge was right, per question, for the current wording only. days: 1–400, default 90.
• The session tools read the same data as the Sessions page.
• In get_session and the sessions:explore tools, each read of stored session data stops after 10 seconds. This does not apply to the read of the rubric. Then the tool answers "Internal error" (500 internal_error at POST /api/agent/<tool>). If only the DevTools read of get_session_full fails, the answer has devtools null and the warning devtools_unavailable. If only the judgments cannot be read in list_watch or list_sessions, the answer has beliefs null and the warning beliefs_unavailable.
• For how the session tools show visitor text, see Privacy at a glance.

• The 401 responses carry a WWW-Authenticate: Bearer header. The 403 response names the missing scope in that header.
• Sequential refuses batched JSON-RPC requests on /mcp.
• A token request spends the rate limit before Sequential checks the project and the scope. This applies to REST and MCP.
• By default, a token does not get a fix brief or a finding that Sequential could not fully screen. An operator can turn this off with FINDINGS_SCREEN_REQUIRED=false. See Privacy at a glance.

Sequential counts the read requests of all tokens of a project together. The limit is 600 requests a minute per project. Server default. The operator changes it with TOKEN_PROJECT_REQUESTS_PER_MINUTE. A value that is 0, empty or not valid gives the default.

• By default, Sequential only counts. It never refuses a request because of this limit.
• The operator can turn the limit on with TOKEN_PROJECT_LIMIT_ENFORCE=true. Any other value, or no value, keeps the default.
• When the limit is on and a project goes over it, Sequential answers 429 project_rate_limited: "Too many requests for this project's access tokens and connections. Try again shortly." The answer has a Retry-After header and retry_after_sec.
• When the limit is on and the store that counts it is unavailable, Sequential answers 503 rate_limit_unavailable, with Retry-After: 30.
• Through MCP, a refused tool call is a tool error, and its text is the same JSON. POST /api/agent/<tool> answers with the same status, body and Retry-After.

What counts:

• A token's GET /api/findings, /api/findings/:n, /api/findings/:n/sessions, /api/findings/:n/brief and /api/findings/:n/verification. Each request counts once. A request that gets 403 or 404 does not count.
• Each call of a tool that only reads, through /mcp, /mcp/readonly or POST /api/agent/<tool>. ask_sessions counts too.
• Write requests never count: record_release, link_fix, POST /api/releases and POST /api/findings/:n/links.

The limit of 120 requests a minute for each token still applies. A request that one of the two limits refuses does not use up the other limit: if the limit for each token refuses it, Sequential gives back its count on the project limit, and if the project limit is on and refuses it, Sequential gives back its count on the token limit (Sequential tries this once, so a count can stay one too high until the minute ends).

Operator note: when the project limit is on and refuses a tool call through /mcp, /mcp/readonly or POST /api/agent/<tool>, the call still counts toward the limit of 120 requests a minute for that token.

• Sequential stores only a hash of each token. It shows the full token once, when you create it.
• If a request has a bearer token and a session cookie, Sequential uses the token. A bad token does not fall back to the cookie.
• Expiry choices in the app: 30 days, 90 days or 365 days. 90 days is selected by default.
• Revoking a token stops it on that server at once. Sequential tells its other servers through Redis. If Redis is down, another server can accept a revoked token for up to 30 seconds.
• A token stops working when its project is archived.
• On the Access tokens tab, the token list can show "It identified itself as" and a name. The agent's MCP client sends this name when it connects. Sequential does not check it, and keeps at most 60 characters.
• Operators change the token rate limit with TOKEN_REQUESTS_PER_MINUTE.
• The token list, GET /api/projects/:id/tokens, gives each token a status. It is live, expired, revoked or paused:project_archived. paused:project_archived means that the project is archived, so the token does not work. On the Access tokens tab, a token that is not live is dimmed and has a badge: Revoked or Expired with the date, or Paused: project archived. On Agents, the Coding agents card shows a paused token with "Paused: project archived" in place of "Used". A revoked or expired token moves to History, as "Revoked" or "Expired" and the day. Only a live token shows its expiry date. Revoke stays on a paused token. In the API, each row also has kind, which is pat for the tokens that you create. last4 can be null, but never for a token that you create.
• A claude.ai connection is in the same list, with kind oauth and no last4. Its status can also be pending, refresh_idle, client_missing or access_lost: and a reason. The app shows these as Connecting, Idle, Client gone and Access lost. A connection that claude.ai never finished shows Never finished connecting, not Expired and a date. A connection on an archived project is paused, and it works again when you restore the project. See Connect claude.ai.