Troubleshooting Sequential

• Three checks explain most missing data.
• The switcher is at the top of the sidebar. Every page shows the selected project.
• Each browser remembers its own project choice. So a teammate can look at a different project.
• Pages show nothing outside the two dates at the top of the page.
• A teammate can see a different range, because each browser remembers its own range.

get_overview has a setup check named ingest_refusals. It tells an agent what Sequential refused or did not store for this project in the window, and why. Or it tells that Sequential refused nothing.

• The check shows at most 3 lines, the largest first. more_reasons counts the others. Each line has the reason, the source, the count, the last day and a sentence.
• A count is of requests: event batches for the Sequential SDK, uploads for recordings, or the requests of another tool's SDK. For replay_event_malformed and heat_host_not_allowed, it is of events.
• A refusal shows about a minute after it happens. Sequential keeps the counts for 30 days, so the oldest day of a 30-day window can be incomplete.
• A request with a wrong or revoked ingest key names no project, so Sequential cannot count it for your project. See No events arrive above.
• If Sequential cannot read the counts in time, the state is unknown.
• A host in a line can be another website that uses your project's public key.
• GET /api/projects/:id/status returns the same lines for the last 7 days, under refusals. In onboarding, the Install step shows them until its card says It works. Other pages do not show them yet.

An agent gets a host or a URL with [person] in it, for example www.[person].com. A value that Sequential knows for a person has the word of your domain in it. Often this is a teammate's sign-up email with a tag, such as name+yourbrand@…, or a test user named after your product.

To fix it, add your site to the list of allowed websites: Settings → Projects → your project → Sources & keys → Allowed websites. From 10 October 2026, Sequential then keeps your own hosts readable for agents. See Privacy at a glance.

The list also refuses data from sites that are not on it. So add every site that runs your snippet. See Organisations and projects.

• "Waiting for the first event from the sources above" stays while a line on the list reads "no events yet". Only Sequential and Session replay can read so. This includes Session replay when you do not record. Read the line for your own source.
• A first event can take up to about a minute to appear. If a project already has some data, a new source can take up to about two minutes to change to "receiving".
• "Used … ago" on Sources & keys only means that a request used the key, for example to get settings. It does not prove that Sequential stores events.

• Keys. Each ingest key works only with its own SDK. Members, admins and owners can see keys. An archived project refuses all its keys. After Restore project, the same keys work again.
• Pendo. Pendo sends with your own Pendo API key. Paste the apiKey from your Pendo snippet.
• Bot traffic. Examples of automated requests: a headless browser, a test runner, curl or a server-side SDK. By design, automated tests do not appear in Sequential.
• Opt-in. Check that your consent banner calls sequential.optIn() when the visitor agrees. data-opt-out is a default, not a stored choice. So sequential.optIn() on one page does not carry to the next page. Do not call it only when the visitor clicks the banner.
• Amplitude batching. Today, batched requests do not reach Sequential's Amplitude handling.
• Session ids. Instead of the recorder, you can register your own $session_id super property.

• Platforms. The Platforms choices are Web, iOS and Android. Uploads that still arrive get 403 replay disabled for tenant or replay disabled for platform.
• Archived project. It refuses its keys. An owner or admin clicks Restore project under Danger.
• PostHog mobile. PostHog's mobile recorder sends app recordings to Sequential. Sequential's own recorder is for websites.
• Session replay key. Sequential SDK and Smartlook installs get the key from Sequential. The project must have a live replay key. Then Setup says "Session replay is included in this tag." Without one, Setup says that session replay needs a live replay key, with a link to Sources & keys.
• Sampling. Staging and development projects start at 10 %. Each session gets its decision once, when it starts. Sessions that already have a decision keep it.
• Short visits. If the visitor leaves a page before Skip sessions under (ms), that page sends nothing.
• URLs. /checkout/** works. A pattern with https:// or ? never matches. If the allow list has entries, only matching pages are recorded. In a single-page app, recording stops at a denied path until the next full page load.
• Strict masking. It masks all text, inputs and most attribute values. It blocks images, SVG, video, audio and iframes. It cuts addresses to their domain.
• Balanced masking. You must type the project slug to switch. Mark sensitive elements with data-sq-mask.
• Caps. When a cap is reached, recording ends for the rest of that page. "Too large" means over the server's upload limit. To keep uploads smaller, block heavy regions with data-rr-block.
• Rate limit. The 50 MB a minute limit applies unless your server sets another value.
• Missing ▶. The recording and your events do not share a session id. Sessions explains how ids are matched. The list stops showing a recording a fixed number of days after its last activity.

• Server upload limit. One upload can be at most 5 MB, unless whoever runs your Sequential server changed it.
• Upload rate limit per IP address. The 50 MB a minute limit also applies to each IP address. So testers on one office network share it.
• Retries. After a 429, the recorder retries after 30 seconds. It keeps only its last 5 waiting uploads.
• When a recording stops playing. The number of days is the "N d" in the Session replay summary line. For a new project, it is 30. After it, Latest shows "Expired" in place of ▶ Replay. In Latest, Watch and the session list of a user, an older session past the first 200 can show ▶ for a moment, until its row gets its state.

• Turning judging on. Owners and admins turn background judging on under Settings → Projects → your project → Insights. Sequential then also judges the unjudged sessions from the past 7 days.
• Judging off, with verdicts. If sessions in the range already have verdicts, Watch keeps the list and shows the reason above it.
• Wider range. Widening the date range includes older sessions.
• Delay. Sequential checks every 5 minutes. A busy project adds delay. When the daily allowance runs out, this also adds delay.
• Counts. "N waiting" and "Not yet judged: N" count all sessions in view that have no judgment.

These never get a judgment:

• Sessions with fewer than 3 meaningful events. By design, very short sessions stay unjudged.
• Events that have no session id.
• Sessions whose last event was already more than 7 days old when judging reached them.
• Sessions where the judge returned an error.

• Storage. Sequential stores every event under one user id. After identify, it is the value your app passes.
• New users from one person. Before identify, each browser has its own anonymous id. So a second device, a private window or cleared storage makes a new user.
• Blocked storage. The browser does not keep the anonymous id between pages.
• Sign-up during a visit. Later events go under your id. With the Sequential SDK, PostHog or Mixpanel, Users lists one user and counts that session once. With Amplitude, Pendo or Smartlook, Users lists both ids, and "Total sessions" counts that session twice. With every SDK, a funnel across sign-up loses people at that step.
• Two values. For example: an email on one screen and an account id on another. Sequential takes the value you pass at face value. Use one identifier for each person. Pass the same value everywhere, every time.
• Smartlook. Other events stay under Smartlook's visitor id.

• The page searches for the exact user id. It does not take the range from Users, Sessions or Watch. Here, the message means "not in this date range".
• Try again reloads the same range.
• A replay's header keeps the day of the recording in the range.

• "Not enough activity to judge — fewer than 3 meaningful events": too little happened in the recording. Nothing to fix.
• "Already judged — same events, same questions, so the verdict below is unchanged.": Re-run has a 10-minute cooldown. Nothing to fix.
• "Insights run once the recording is ready (by 14:05).", with the time when the recording is ready: the recording is still being processed. Keep the replay open: the tab judges it on its own once the player loads the recording. If the player stopped checking, select Check now.
• "This recording has expired, so it can't be judged.": the replay period ended. Nothing to fix.
• Allowance reset. The tab shows the reset in your local time and as 00:00 UTC.
• While the allowance is used. Judgments saved in the last 7 days still open, unless someone edited the project's questions since then. If a verdict is already on screen, it stays. Re-run is hidden, because it cannot make a new judgment.
• Not set up. On-demand judging is not configured on your Sequential server.
• Time-out. If the judgment finished in the meantime, Retry gets it, and no new judgment is made.
• Cooldown. Within 10 minutes of a Re-run that made a new judgment on the same session, another Re-run keeps the saved judgment.

• The two dates at the top of the page default to UTC dates.
• Some times are converted, some are not. The Sessions, Users and Events lists show a relative time, such as "3 h ago". Hover it for your local time. Ask results show your local time.
• A chart day runs from midnight to midnight UTC. So evening activity in the Americas counts on the next UTC day.
• In a funnel's drill-down, the user detail page can show the UTC time without conversion.

• The recorder takes the user id from PostHog, Amplitude, Mixpanel, Pendo or the Sequential SDK on the page. It does not read a user id from the Smartlook compatibility script.
• The recorder reads the user id of the Sequential SDK from the storage of the browser.
• Your events still carry the identified id.

• Raw event data. The icon opens the Raw event data window. It shows the stored properties of the event.
• Filters. is on Text matches only the exact text of a value. For a number or a date and time, choose the type Number or Date.
• JSON. Examples of values the SDK cannot turn into JSON: a BigInt, or an object that refers to itself. Sequential stores objects and arrays as JSON text.
• Mixpanel $ properties. Sequential drops them when it stores the event.
• URLs. Sequential redacts query values when it stores them.
• User properties. Check the support matrix before you rely on user properties.

• Sequential SDK. It keeps identify() properties on the $identify event that the call sends. A repeat sequential.identify() with the same id and the same properties sends nothing. From 11 October 2026, a repeat with changed properties sends a new $identify event with them.
• PostHog. Sequential keeps $set and $set_once only when they arrive on a $set event. That event comes from posthog.setPersonProperties() or a repeat identify with the same id.
• Mixpanel. Sequential refuses people.set from the browser today.