Signals

Overview

A Signal is any single problem indicator LogRocket detects in your app. Signals are the raw evidence layer: they're created automatically as LogRocket ingests data, there are a lot of them, and most of them never need your attention.

An Issue is what you do about a Signal. Each Issue groups one or more related Signals and carries a priority, a status, an assignee, an AI analysis, linked tickets, and a dispatched coding agent.

A Signal is what happened in your app. An Issue is what you're doing about it.

This page is the reference for every Signal type — what it detects, where it lives, and how it behaves. For the Issue lifecycle (priority, status, assignee, coding agents, the Issues Feed), see Issues.

Signal types

More Signal types coming soon.

What every Signal has in common

Regardless of type, every Signal behaves the same way in a few important respects.

Severity

Every Signal is evaluated for severity by Galileo AI — a measure of how likely the problem is to frustrate users or block them from completing a task. Severity is owned by Galileo; it isn't something you set by hand, and each Signal is re-evaluated on a rolling basis.

Galileo uses severity to decide which Signals are important enough to open an Issue automatically. See Signal Severity and Severe Issues via Galileo AI.

Opening an Issue

There are two ways a Signal becomes an Issue:

• Automatically. When a Signal's severity crosses Galileo's threshold, LogRocket opens an Issue for it at High priority and attaches Galileo's analysis.
• Manually. Choose Open Issue from any Signal. If Galileo has determined the Signal is not severe, the new Issue starts at Low priority.

Signals you never open into an Issue stay in their source view with their full stats and history — they simply don't carry a priority, assignee, tickets, or agents until you open one.

Ignoring a Signal

Ignoring a Signal tells LogRocket not to create or join Issues from that Signal again. Closing an Issue marks all of its underlying Signals as ignored.

Analysis

Each Signal carries its own AI-generated analysis. When an Issue has one primary Signal, that Signal's analysis becomes the Issue's analysis; when additional Signals join, the analysis is regenerated across all of them.

Grouping

Only Signals of the same type can be combined into a custom group. You can, however, link Signals of different types into the same Issue when they share an underlying fix — a Feedback Signal describing a broken checkout and the Error Signal behind it belong together. See Grouping and linking Signals.

Retention

Issues and Signals are retained for 1 month from the last instance, independent of your organization's session retention.

---

Errors

The Errors view is the home for Error Signals. It behaves much like the Issues experience you may know from before: every error group, with its stats, histogram, sessions, custom grouping conditions, and the deep-debug detail surface. From here you can configure Errors Digests and open an Issue from any Error.

Error detail

For an Error Signal, the detail surface gives you the deep-debug view: a sample session playback of a user hitting the error, the stack trace (when you've provided sourcemaps), browser and OS breakdowns, affected sessions, and the histogram of occurrences. This is also the only place you configure custom grouping conditions for Errors.

If an Error isn't yet tracked as an Issue, its detail surface shows a prominent Open Issue action. If it is, it shows a link up to the Issue it belongs to.

Platform

Each Error Signal is comprised of events from a single platform — Browser, iOS, or Android — and you can filter by platform. Because React Native compiles to native code, apps using the React Native SDK will find errors under the iOS and Android platforms.

URL grouping configurations

Network error Signals support optional URL grouping configurations, adjustable in the Errors settings view. This gives better visibility into the scope of problems in apps with subdomains or domain extensions that represent the same underlying experience.

Exclude URL Subdomains should be enabled when an API's multiple subdomains represent the same basic API — for example, when account keys are used as subdomains, like customer1.app.com/foo/bar and customer2.app.com/foo/bar. This groups across subdomains as *.app.com/foo/bar.

Exclude URL Domain Extensions should be enabled when an API uses multiple domain extensions that all represent the same basic API, such as app.com/foo/bar and app.co.uk/foo/bar. This groups across domain extensions as app.*/foo/bar.

High-Volume Boost

For customers with more than 1M monthly sessions, enabling High-Volume Boost increases the speed at which Errors and Issues load across the app by querying in a way tuned for higher event counts. This configuration is not recommended for customers with fewer than 1M monthly sessions.

Error Event Types

These error event types occur within sessions. When grouped into Error groups, they're considered a signal that can be opened into an Issue.

• Exceptions
• Network Errors
• Crashes
• Error States
• Dead Clicks
• Rage Clicks
• Frustrating Network Requests

Exceptions

An exception is a JavaScript (client-side), iOS, or Android error thrown by your application. Exceptions may or may not directly impact the UI — some halt a critical flow, while others fire silently in the background. Weighing that difference is what session replay and severity are for.

How LogRocket detects an exception

LogRocket captures exceptions automatically after you install the SDK — no extra setup is required for uncaught errors:

• Web — uncaught JavaScript exceptions. If a framework swallows errors (for example Angular's ErrorHandler or Ember's Ember.onerror), re-throw them or pass them to LogRocket.captureException() so LogRocket can see them.
• iOS and Android — uncaught exceptions from the native SDKs. Because React Native compiles to native code, React Native exceptions appear under the iOS and Android platforms.
• Manual reporting — use captureException() (and on web, captureMessage()) to report caught errors you still want tracked, optionally with tags and extra metadata.

In session replay, exception events appear in the Logs pane. Stack traces resolve to original source when you've provided sourcemaps (web) or mapping files (Android, iOS, React Native).

How exceptions are grouped

Exceptions are grouped by their stack and message so the same underlying failure lands in one exception group.

Network Errors

A network error is a failed network request or a GraphQL error. Like exceptions, these may or may not directly impact the UI — a 500 on a critical checkout call is very different from a failed analytics beacon.

How LogRocket detects a network error

LogRocket records a network error when a captured request fails. That includes:

• HTTP responses that indicate failure (for example 4xx and 5xx status codes)
• Requests that never completed successfully, including those with a status of 0 (blocked, aborted, or offline)
• GraphQL errors returned in a GraphQL response

In session replay, network error Signals appear in the Network pane, with request and response details available on the Signal's detail surface.

How network errors are grouped

Network errors are grouped by request method and URL pattern. You can refine that grouping with URL grouping configurations in Errors settings — collapse subdomains or domain extensions that represent the same API. See URL grouping configurations above.

Crashes

A crash is when an iOS or Android app terminates unexpectedly. Crashes are among the highest-impact Error Signals: they end the session, interrupt the task, and weigh heavily in App Store and Play Store ranking.

How LogRocket detects a crash

With the mobile SDKs installed, LogRocket captures crashes automatically — no additional configuration is required. Supported crash types include uncaught Java exceptions on Android, and on iOS uncaught Objective-C exceptions, Mach kernel exceptions, and C++ exceptions. See Mobile Crash Types for the full matrix and SDK version requirements.

Upload mapping files to de-obfuscate stack traces: Android, iOS, React Native.

Error States

An error state is a moment when your UI shows the user that something went wrong — an error page, a failed-to-load modal, an empty state that says "couldn't load," and similar. Error states catch problems that might or might not have thrown an exception: the request might have "succeeded," the code might have kept running, and the user still hit a wall.

How LogRocket detects an error state

Error states are driven by Element Visible definitions you mark as error states:

1. Create (or open) an Element Visible definition in Definitions.
2. Check Use as Error State option.
3. From that point on, whenever that element becomes visible in a session, LogRocket records an error state event. The error state events then appear in the Event Timeline of session replay.

Note: Element Visible definitions are non-retroactive — they only capture matches after you create them. New projects get a set of default error state definitions for common error phrases; review and edit those so they match your app's real copy.

Dead Clicks

A dead click is a click that did nothing. The user clicked something that looked interactive, and your app didn't respond — no content changed, nothing navigated, no dialog opened. Dead clicks are one of the clearest indicators of a broken or misleading interface, because the user has already told you what they expected to happen.

How LogRocket detects a dead click

Detection has two parts: whether the element the user clicked was one we evaluate at all, and whether anything happened afterward.

Which elements are eligible. LogRocket only classifies a click as dead if the clicked element looks interactive. An element qualifies if any of the following is true:

• It's an interactive tag: a, button, input, details, dialog, menu, or summary.
• Its CSS cursor implies an interaction: pointer, context-menu, help, zoom-in, or zoom-out.
• It has an interactive ARIA role: button, checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, separator, slider, spinbutton, switch, tab, tablist, tabpanel, textbox, treeitem, combobox, grid, listbox, menu, menubar, radiogroup, tree, or treegrid.

Elements with no text are also excluded.

What counts as a response. Once an eligible element is clicked, LogRocket watches for a short window. If none of the following occurs in that window, the click is recorded as a dead click:

• A DOM change — nodes added, removed, or changed, or the page scrolls
• A style change — inline styles, stylesheet contents, or adopted/constructed stylesheets change
• A navigation
• Input — the user types, or focus moves into an input, select, or textarea
• A dialog opens

How dead clicks are grouped

Dead clicks are grouped by the element's context and its location in your application, not by its text alone. Grouping by text alone produces two problems that our algorithm fixes:

• Over-grouping — multiple forms with the same button label ("Submit") that fail in different ways are not collapsed into one group.
• Under-grouping — the same action with slightly different labels ("Pay $50", "Pay $75") is still grouped as in a single group.

To see which text variations are included in a dead click Signal, open the Signal and check the Event Distribution section.

Note: Dead clicks are captured in web apps, but not in Android or iOS. See Mobile Feature Support.

Rage Clicks

A rage click is a burst of rapid, repeated clicks on the same element — the user's way of saying "this isn't working." Rage clicks often point to unresponsive controls, slow UI updates, or interactions that look clickable but aren't.

How LogRocket detects a rage click

On web, LogRocket records a rage click when a user performs a series of rapid, repeated clicks on the same element. On mobile, the equivalent is repeated taps in a small area of the app in a short period of time. Scrolling alone is not treated as a rage click.

In session replay, rage click events appear in the Event Timeline.

How rage clicks are grouped

Rage clicks are grouped the same as dead clicks. See above.

Frustrating Network Requests

A frustrating network request is a compound event: a particularly long network request and impatient user behavior while waiting for it. The request eventually may succeed — what LogRocket is flagging is that the wait felt broken to the user.

How LogRocket detects a frustrating network request

Detection requires both halves of the compound event:

• A network request that takes an unusually long time to complete
• User behavior during that wait that indicates impatience — scrolling, clicking, or mouse movement

Frustrating network requests are supported on web only; they are not captured on iOS or Android. In session replay, they appear in the Event Timeline.

How frustrating network requests are grouped

Frustrating network requests are grouped by request method and URL pattern, and they share the same grouping controls as Network Errors: URL grouping configurations in Errors settings — see URL grouping configurations above.

Availability

---

Feedback

A Feedback Signal is a cluster of qualitative customer feedback that describes a problem in your product. Feedback ingests customer support conversations, survey responses, and app-store reviews from tools like Intercom, Zendesk, Alchemer, G2, and the Apple App Store and Google Play Store, then uses Galileo AI to cluster and tag them, track sentiment, and connect each one to the session replays that prove it.

Feedback Signals close the loop between what customers say and what your team fixes. A support cluster that keeps growing is a problem worth tracking whether or not it ever threw an exception.

How Feedback Signals are created

Galileo generates an analysis for each feedback cluster and evaluates it for severity the same way it evaluates Errors.

Working with Feedback Signals

• Each row in the Feedback tables shows its Associated Issue, if one has been opened.
• The Feedback detail sidebar links up to the Issue the cluster belongs to.
• From a feedback cluster, choose Open Issue to start tracking it.
• Because Feedback Signals and Error Signals can share an Issue, you can link the customer complaints and the underlying exception into a single unit of work.

---

Release Recaps

A Release Recap Signal is a problem Galileo AI found while analyzing how users actually behaved after you shipped something.

Release Recaps scan your Jira or Linear instance every week for newly-completed tickets, work out which ones correspond to user-facing changes, and watch sessions to determine how each change is actually performing. When that analysis turns up something wrong — a regression, a feature nobody found, a step where users consistently get stuck — LogRocket raises it as a Release Recap Signal so it lands in the same Issues workflow as everything else.

This is the difference between "we shipped it" and "it works." Errors tell you the code broke. Release Recaps tell you the experience did.

How Release Recap Signals are created

A single Recap can surface more than one problem. LogRocket extracts and classifies each one separately, so what reaches your Issues Feed is the individual problem, not the whole Recap.

Each extracted problem is scored for severity like any other Signal, and severe ones open an Issue automatically.

Because Recaps run weekly, Release Recap Signals appear on that same weekly cadence.

Recap generation modes

Release Recap generation is configurable per app in the settings modal on the Release Recaps page:

• Auto — Galileo decides what to recap, in addition to any manually tagged tickets.
• Manual — only manually tagged tickets are recapped.
• Off — no recaps are generated for that app.

You can also force a Recap for a specific ticket by adding a logrocket tag to it or commenting @logrocket on it.

Resolution

Release Recap Issues do not auto-resolve. Because each Recap is a point-in-time analysis rather than an ongoing stream of events, there's no "stopped occurring" condition to detect — you resolve or close these Issues yourself once the problem is addressed.

---

Streams

A Stream Signal is a problem Galileo AI found in a scheduled Discover stream run.

A stream is a recurring question you set up to monitor a specific critical area of your app — for example, "What are the top new issues in checkout this week?" Galileo answers it on a daily or weekly schedule, and when a run turns up a real problem, LogRocket raises it as a Stream Signal so it lands in the same Issues workflow as everything else.

Streams are the one Signal type where you tell LogRocket where to look, which makes them the way to keep watch on the flows you can least afford to break.

How Stream Signals are created

You create and manage streams from Discover. Each stream has a question Galileo should answer and an interval — daily or weekly — for how often to run it.

When a scheduled run turns up a problem, LogRocket extracts it as a Stream Signal, scores it for severity like any other Signal, and opens an Issue automatically if it is severe.

LogRocket won't re-raise a finding it has already surfaced from a recent run, so a recurring stream doesn't produce duplicate Issues week over week. Because streams run on the cadence you choose, Stream Signals appear on that same daily or weekly schedule.

Stream detail

For a Stream Signal, the detail surface shows the sessions Galileo cited when it validated the finding, and a link back to the stream run it came from.

Resolution

Stream Issues do not auto-resolve. Because each stream run is a point-in-time analysis rather than a continuous event source, there's no "stopped occurring" condition to detect — you resolve or close these Issues yourself once the problem is addressed.

---

Related

• Issues - the Issue lifecycle, the Issues Feed, and Issue Detail
• Signal Severity
• Errors Digests
• Issues Alerts
• AI Coding Agents
• Feedback
• Galileo Discover