Published February 11, 2026
Part 3 of 3: Rage Click Detection with LaunchDarkly
## Overview
In [Part 1](/tutorials/detecting-user-frustration-session-replay), we set up rage click detection using LaunchDarkly's [Session Replay](/home/observability/session-replay). In [Part 2](/tutorials/connecting-rage-clicks-to-guarded-releases), we connected those frustration signals to [guarded releases](/home/releases/guarded-rollouts) for automated rollback protection.
Now it's time to put it all together. In this final installment, we'll walk through real-world debugging scenarios using our WorkLunch app—a cross-platform application built with React Native and Expo where coworkers can swap lunches.
These scenarios demonstrate how the integrated system of feature flags, session replay, and guarded releases can transform the way you diagnose and fix production issues.
All code for this blog post can be found [here](https://github.com/arober39/worklunch).
## The Debugging Workflow: An Observability Loop
Before diving into scenarios, let's understand the complete workflow we've built:
This workflow enables you to:
* **Detect** frustration signals automatically as they happen.
* **Alert** when thresholds are breached during rollouts.
* **Investigate** with full session context, not just error logs.
* **Fix** with confidence knowing the exact user experience.
* **Verify** the fix works by monitoring the new rollout.
When a guarded release detects a spike in rage clicks, it automatically correlates the frustration with specific flag variations:
The alert tells you exactly which feature caused the problem: "Rage clicks increased 10x for users on `join-community-redesign: true`" It’s important to note that rage clicks aren’t the only measure for frustration signals around user experience.
When items are out of place, confusing or navigation is not consistent across mobile and web, it can cause users to rage scroll. Unlike rage clicks that can be measured and tracked, rage scrolls are a little more nuanced, which will result in relying heavily on session replay and drops and traffic to diagnose.
Just as llm observability tools monitor model outputs for hallucinations or drift, rage click detection monitors the human layer, catching UX failures that no server-side metric would reveal.
Using feature flags, session replay and guarded releases, let’s take a closer look at both scenarios to debug in a real-world worklunch app.
## Scenario 1: Form Validation Frustration
### The Setup
Your team ships a new "Create Community" button redesign and places the feature behind a feature flag called (`inline-form-validation`).
After the feature flag is toggled on, you notice users on this form are rage clicking the Create Community button. Your metrics show community creation conversions dropped 15 percent since enabling the flag, but there are no errors in the logs.
Thankfully, you connected your feature flag with a Guarded Release and can use it to debug the issue.
### Investigation Steps
Step 1: Search for sessions with rage clicks
Since we attached a Guarded Rollout to your feature flag using a metric for detecting rage clicks, we can navigate to the LaunchDarkly’s Session page and filter for those specific sessions.
In the LaunchDarkly Sessions tab search bar, apply this filter:
```
has_rage_clicks=true featureflag.key=inline-form-validation
```
This query filters for sessions with rage clicks and where the inline-form-validation flag is enabled.
Step 2: Watch for user behavior patterns
In the session replay, you see:
1. User fills out the form completely.
2. User clicks Create Community.
3. User sees a loading spinner and nothing else.
4. User clicks button repeatedly.
5. User abandon forms altogether.
Step 3: Identify the UX failure
The community was being created successfully meaning the API returned a 200 and the new community existed. The new feature was intended to simply change the button color (baby blue → purple), but it **broke the code that allows the success card to be shown**.
### The Root Cause
When the flag is off, the code does the right thing after a successful create:
1. Success → Set `createdSpace` → Show verification card (name, join code, "Back to community list")
2. User taps Back → Return to community list
When the flag is on, the success path was missing:
1. Success → Nothing. The `if (!useInlineValidation)` block runs only for the old flow, so when the flag is on, `setCreatedSpace` is never called.
2. The user stays on the form with no confirmation, no join code, and no way to know the create worked.
```typescript theme={null}
// Only the control (flag OFF) got success UI; the treatment (flag ON) did not
if (!useInlineValidation) {
setCreatedSpace({ name: space.name, join_code: space.join_code });
}
```
### The Fix
To fix the issue, you can either rollback to previous working code or fix the issue and toggle flag back on.
Option A – Roll back the flag: Set `inline-form-validation` to off in LaunchDarkly. Users are no longer on the new feature; they get the existing, working code path and see the verification card after Create Community.
Option B – Fix the new feature so it no longer breaks the success card: The new feature (flag on) breaks the code that shows the success card. Fix it by adding the success handling to the flag-on path. Also, when the flag is on, also call `setCreatedSpace` after a successful create so the success card is shown again.
### Resolution
With the root cause identified from Session Replay, you update the code and resolve the rollout:
1. Roll back `inline-form-validation` to `false` so users get the verification card and can return to the list (instant, no deployment needed).
2. Fix the flag-on success path so it shows the verification card (or redirects) after create.
3. Deploy and re-enable the flag with the guarded rollout (rage click metrics) still attached, then monitor to confirm rage clicks return to baseline.
Time to resolution: 30 minutes to an hour (compared to potentially days of user complaints and support tickets).
## Scenario 2: The Infinite Scroll Frustration
### The Setup
Your team ships a feature flag (`new-filter-location`) that moves the existing Category and Sort controls on the "Lunches for Swap" feed from the top of the list to the bottom.
Everything works fine until you notice a drop in traffic.
Since you see no uptick in rage clicks for your Guarded Release, you know it must be another user signal you’re missing that could indicate user frustration. So you decide to investigate further by placing yourself in the user's shoes using session replay.
### Investigation Steps
Step 1: Filter by flag variation
```
feature_flag.key=new-filter-location feature_flag.result.value=true
```
This query will filter for sessions where the feature flag `new-filter-location` is set to true.
Step 2: Watch for user behavior patterns
In session replay, you see:
1. users scroll down the feed, then back up, then down again.
2. Minimal item taps.
3. Constantly moving through the list without making selections.
4. User navigates to a different page.
The pattern suggests they're looking for something rather than browsing items.
Step 3: Identify UX Failure
Replay shows the issue: “Category” and “Sort” are not at the top where users expect them. With the flag on, the controls were moved to below every post in the feed.
### The Root Cause
The feature flag moves the existing filter bar from the top to the bottom of the list (`ListFooterComponent` when the flag is on). Same controls, different position.
```typescript theme={null}
// Flag ON: same filter bar rendered as ListFooterComponent — breaks user expectation
ListFooterComponent={
useFiltersAtBottom ? (