---
updatedAt: 2026-10-06T19:32:59.000Z
agentTools:
  projectIndex: https://docs.logrocket.com/llms.txt
---

# Signals

Every Issue source LogRocket detects: errors, feedback, release recaps, and streams

## 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](https://docs.logrocket.com/docs/issues-2026) 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](https://docs.logrocket.com/docs/issues-2026).

## Signal types

| Signal type        | What it detects                                                                                                                                                    | Where it lives      | Ongoing events?                                 |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------- | ----------------------------------------------- |
| **Errors**         | Exceptions, network errors, mobile crashes, error states, dead clicks, rage clicks, and frustrating network requests. These may or may not directly impact the UI. | Errors view         | Yes                                             |
| **Feedback**       | Clusters of qualitative customer feedback — support conversations, survey responses, and app-store reviews — that describe a problem in your product.              | Feedback view       | Yes                                             |
| **Release Recaps** | Problems and regressions Galileo AI identifies while analyzing how users actually behaved after a feature shipped.                                                 | Release Recaps view | No, each Recap is a point-in-time analysis      |
| **Streams**        | A problem Galileo found in a scheduled Discover stream run. Streams are set up by you to monitor specific critical areas of your app.                              | Streams view        | No, each stream run is a point-in-time analysis |

*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](https://docs.logrocket.com/docs/signal-severity) and [Severe Issues via Galileo AI](https://docs.logrocket.com/docs/severe-issues).

### 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.

### Customizing ignore rules

A one-click ignore applies to the whole Signal. To control which events the ignore covers, edit its rules:

1. Go to **Issues > Errors > Ignored**.
2. Click **Edit ignore rules** in the top right.
3. In the panel, find the ignored error and click the edit icon on a rule to broaden or narrow the events it matches, then save.

Ignore rules are only available for **Exceptions**, **Network Errors**, and **Frustrating Requests** error signals. Other error signal types support one-click ignore only.

### 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](https://docs.logrocket.com/docs/issues-2026#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](https://docs.logrocket.com/docs/issues-digests) and open an Issue from any Error.

<Callout icon="📘" theme="info">
  ### **Errors consolidate the old issue types**

  The problem types you may know from the previous Issues experience — Network Errors, Rage Clicks, Dead Clicks, Frustrating Network Requests, Error States, and Mobile Crashes — are all detected as **Error** Signals. You'll find them in the Errors view.
</Callout>

### 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](https://docs.logrocket.com/docs/stacktraces)), 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](#exceptions)
* [Network Errors](#network-errors)
* [Crashes](#crashes)
* [Error States](#error-states)
* [Dead Clicks](#dead-clicks)
* [Rage Clicks](#rage-clicks)
* [Frustrating Network Requests](#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](https://docs.logrocket.com/docs/signal-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()`](https://docs.logrocket.com/reference/capture-exception) 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](https://docs.logrocket.com/docs/stacktraces) (web) or mapping files ([Android](https://docs.logrocket.com/reference/stack-traces-android), [iOS](https://docs.logrocket.com/reference/stack-traces-ios), [React Native](https://docs.logrocket.com/reference/stack-traces-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.

<Callout icon="🚧" theme="warn">
  ### **Network traffic is sampled**

  LogRocket samples network events before processing them, so not every failed request becomes a Network Error Signal with severity and an Issue link. See [Signal Severity](https://docs.logrocket.com/docs/signal-severity).
</Callout>

#### How network errors are grouped

Network errors are grouped by [Network Endpoint Grouping](https://docs.logrocket.com/docs/network-endpoint-grouping). You can refine that grouping to collapse subdomains or domain extensions that represent the same API with [URL grouping configurations](#url-grouping-configurations) in Errors settings.

### 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](https://docs.logrocket.com/docs/mobile-crash-types) for the full matrix and SDK version requirements.

Upload mapping files to de-obfuscate stack traces: [Android](https://docs.logrocket.com/reference/stack-traces-android), [iOS](https://docs.logrocket.com/reference/stack-traces-ios), [React Native](https://docs.logrocket.com/reference/stack-traces-react-native).

<Callout icon="📘" theme="info">
  ### **Browser crashes are separate**

  Chrome/Edge browser crashes can be correlated with web sessions via the [`Reporting-Endpoints` header](https://docs.logrocket.com/docs/crash-logging-configuration), but those appear as crash events in session replay — they are not the Crash Error Signal type described here, which covers mobile app crashes.
</Callout>

### 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](https://docs.logrocket.com/docs/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](https://docs.logrocket.com/docs/definitions#default-error-state-definitions) for common error phrases; review and edit those so they match your app's real copy.

<Callout icon="📘" theme="info">
  ### **Quickstart: default error state definitions**

  The fastest way to start capturing error states is to let LogRocket create the defaults for you. From the Errors view, open the error-type filter, choose **Setup** next to Error States, and — if you have none yet — click **Create Default Error State Definitions**. Then replace the defaults with definitions that match the error UI your users actually see.
</Callout>

### 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**

<Callout icon="🚧" theme="warn">
  ### **Clicks on non-interactive elements are not dead clicks**

  If your app uses a plain `<div>` as a button, clicks on it are never classified as dead clicks, even when nothing happens. Give the element a `<button>` tag, an interactive ARIA role, or a `cursor: pointer` style — all three also improve accessibility.
</Callout>

#### 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](https://docs.logrocket.com/docs/mobile-feature-support#issue-management).

### 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](#how-dead-clicks-are-grouped).

### 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](#url-grouping-configurations) above.

### Availability

<Callout icon="🚧" theme="warn">
  ### **Plan availability**

  Exceptions are available on all plans. Non-JavaScript Error Signal types — Network Errors, Rage Clicks, Dead Clicks, Frustrating Network Requests, Error States, and Crashes — are available on paid plans only.
</Callout>

***

## Feedback

<Callout icon="📘" theme="warn">
  ### Private Beta

  Feedback as a signal for opening Issues is currently in private beta.
</Callout>

A **Feedback** Signal is a cluster of qualitative customer feedback that describes a problem in your product. [Feedback](https://docs.logrocket.com/docs/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.

<br />

***

## Release Recaps

<Callout icon="🧪" theme="warn">
  ### Private Beta

  Release Recaps as a signal for opening Issues is currently in private beta.
</Callout>

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

[Release Recaps](https://docs.logrocket.com/docs/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.

<Callout icon="🚧" theme="warn">
  ### **Requires a Jira or Linear integration**

  Release Recaps reads your completed tickets, so Release Recap Signals only appear for apps with the [Jira](https://docs.logrocket.com/docs/jira) or [Linear](https://docs.logrocket.com/docs/linear) integration configured. Release Recaps is currently in beta — contact [support@logrocket.com](mailto:support@logrocket.com) for access.
</Callout>

### 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

<Callout icon="🧪" theme="warn">
  ### Private Beta

  Streams as a signal for opening Issues is currently in private beta. Contact [support@logrocket.com](mailto:support@logrocket.com) to have Stream Signals enabled for your organization.
</Callout>

A **Stream** Signal is a problem Galileo AI found in a scheduled [Discover](https://docs.logrocket.com/docs/galileo-discover-alpha) 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](https://docs.logrocket.com/docs/galileo-discover-alpha). 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](https://docs.logrocket.com/docs/issues-2026) - the Issue lifecycle, the Issues Feed, and Issue Detail
* [Signal Severity](https://docs.logrocket.com/docs/signal-severity)
* [Errors Digests](https://docs.logrocket.com/docs/issues-digests)
* [Issues Alerts](https://docs.logrocket.com/docs/issues-alerts-2026)
* [AI Coding Agents](https://docs.logrocket.com/docs/coding-agents)
* [Feedback](https://docs.logrocket.com/docs/feedback)
* [Galileo Discover](https://docs.logrocket.com/docs/galileo-discover-alpha)