From “Something Feels Off” to a Place You Can Actually Investigate: Debugging with HeronSignal

A user tells you that something is broken.

You check your error tracker, but there is no obvious spike. The latest deployment looks normal, the server is running, and nothing immediately explains what the user experienced.

At that point, debugging often turns into guesswork. You ask for screenshots, try to reproduce the issue yourself, and start checking different browsers, devices, or user flows without knowing where the problem actually occurred.

HeronSignal is designed around a different workflow. Instead of treating analytics, session data, user struggle, errors, performance, and debugging as separate investigations, it helps you move through the same chain: notice that something is wrong, understand who is affected, inspect what happened, and bring the relevant production context into your development workflow.

Here is what that process looks like.

1. Start With What Needs Your Attention

The first thing you see in HeronSignal is not a collection of charts that you have to interpret manually.

You see what currently needs attention.

HeronSignal surfaces open findings and groups the investigation around areas such as advisor findings, error groups, sessions, clips, logs, metrics, and alarms. This gives you an immediate starting point when something in production needs investigation instead of forcing you to search through multiple dashboards to figure out where to begin.

Below that, you can still see the current state of the application through metrics such as visitors, errors, typical load time, users leaving after one page, and live activity.

The difference is that the dashboard gives you both the overall picture and a path toward the things that may actually require investigation.

For example, you might see a new error group, an advisor finding, or a change in performance that deserves a closer look. From there, you can move into the relevant part of the product instead of starting with a completely open-ended debugging process.

2. Use Insights to Understand What Changed

Once you have an area worth investigating, Insights gives you a broader view of how the application is behaving.

You can look at metrics across different time ranges and explore areas such as visitor breakdown, pages, geography, network activity, events, and clicks. This helps establish whether the problem is isolated or part of a larger change in user behavior.

Imagine that page views are stable, but returning visitors suddenly drop. Or perhaps sessions are declining while traffic remains relatively unchanged. A change like that does not automatically tell you what is broken, but it gives you something concrete to investigate.

You can then narrow your attention to specific pages, visitor segments, events, clicks, browsers, locations, or other available context.

This matters because debugging an entire production application is usually inefficient. The goal is to reduce the surface area of the investigation before you start looking for a technical cause.

Insights helps answer the first question:

What changed?

3. Find the Sessions Behind the Data

Metrics can tell you that something changed, but they cannot always explain what an individual user experienced.

That is where Sessions becomes useful.

A session gives you the actual journey of a visitor through your application. You can see information such as where they came from, their country and city, and the sequence of events that occurred during their visit.

For example, instead of knowing only that users are visiting your website and leaving, you can inspect a session and see a journey such as:

Visited the homepage
        ↓
Clicked Teams
        ↓
Navigated to another page
        ↓
Performed additional actions
        ↓
Left the site

The exact journey gives you context that aggregate analytics cannot provide on its own.

If a particular page has an unusual exit rate or a group of users appears to encounter the same problem, you can move from the metric to the actual sessions involved.

Instead of asking, "Why are users leaving this page?" you can start looking at what they actually did before they left.

4. Use Clips to Find User Struggle

Not every production problem appears as a JavaScript error.

Sometimes the application technically works, but users clearly struggle to use it.

A button may look clickable when it is not. A request may take too long to respond. An element may fail to react to user input. A form may appear stuck.

HeronSignal records Clips when it detects signs that a user may be struggling, including interactions such as rage clicks and dead clicks.

A rage click happens when a user repeatedly clicks the same area because they expect something to happen. A dead click can indicate that a user clicked an element that did not produce the expected response.

This can be one of the fastest ways to discover problems that would otherwise be invisible.

Imagine several users clicking a checkout button repeatedly before leaving the page. Your error count may still look normal, but the interaction itself tells you that something is wrong.

The button could be broken. The request could be slow. The loading state could be unclear. The click target might not be responding on a specific device.

The point is that you no longer have to start by guessing.

You have evidence that users are struggling with a specific interaction.

That changes the investigation from:

"Someone said checkout feels broken."

to something much more concrete:

"Multiple users repeatedly clicked the checkout button without getting the expected response."

5. Connect User Behavior With Technical Context

Finding a struggling user is only part of the debugging process.

The next step is understanding why the problem happened.

A user repeatedly clicking a button is the visible symptom. The underlying cause could be a failed request, a JavaScript error, a browser-specific issue, a performance problem, or something else entirely.

HeronSignal brings together multiple types of production context so the investigation does not stop at the user behavior.

You can move between areas such as:

• Sessions
• Clips
• Error groups
• Logs
• Metrics
• Alarms
• Advisor findings

This allows you to investigate the same issue from more than one angle.

For example, you might start with an advisor finding that points to a problem worth investigating. You then check the relevant metrics and notice a change in behavior, inspect the affected sessions, find clips showing repeated interactions, and finally discover an error or log entry connected to the same flow.

The investigation gradually becomes narrower.

A vague production problem turns into a specific chain of evidence.

6. Give Your Coding Agent the Production Context

Even after you understand the issue, there is usually one more problem: transferring everything you found into your development environment.

Traditionally, this means manually copying error messages, session details, screenshots, reproduction steps, logs, and your own interpretation into another tool.

Important details can easily get lost during that process.

With HeronSignal's MCP integration, your coding agent can access HeronSignal's production context directly as part of the investigation.

Instead of giving your agent a vague description such as:

"Checkout seems broken on Safari. Some users clicked the button multiple times. I found an error, but I'm not sure if it's related."

you can investigate with the relevant production context available to the agent.

The workflow becomes:

Advisor finding or production signal
                ↓
        Insights and metrics
                ↓
         Affected sessions
                ↓
      Clips showing user struggle
                ↓
     Errors, logs, and performance
                ↓
      Coding agent investigation

The goal is not to replace debugging with AI.

The goal is to reduce the amount of context you have to manually reconstruct before debugging can begin.

Your coding agent starts with a clearer picture of what happened in production instead of relying only on a short description of the problem.

7. Move From the Symptom to a Reproducible Bug

By this point, the investigation should be much more specific.

Instead of saying that "checkout is broken," you may have something like this:

Problem:
Users are struggling to complete checkout.

Observed behavior:
Multiple affected users repeatedly click the checkout button.

Session context:
The behavior appears during the payment flow.

Technical context:
A related error occurs during payment initialization.

Scope:
The issue appears to affect a specific browser or device group.

Investigation starting point:
Check the payment initialization flow and
browser-specific handling.

This is a much stronger starting point for debugging.

You have a visible symptom, evidence of user behavior, affected sessions, and technical context that can help narrow down the cause.

The bug may still require investigation, but you are no longer starting from an unstructured report.

The Full Production Debugging Workflow

A production issue does not always begin with an error alert.

Sometimes the first sign is an advisor finding. Sometimes it is a change in metrics. Sometimes users begin leaving a page more often. Sometimes HeronSignal detects repeated clicks or interactions that are not producing the expected result.

A practical debugging workflow looks like this:

1. Notice what needs attention

Start with the findings, error groups, metrics, alarms, or other production signals that indicate something may require investigation.

2. Understand what changed

Use Insights to examine changes in traffic, sessions, pages, visitor behavior, events, clicks, or other available data.

3. Narrow down the affected users

Move from the aggregate data to the sessions behind the behavior and inspect the journey of users who may have encountered the issue.

4. Look for signs of struggle

Use Clips to identify interactions such as rage clicks and dead clicks that may reveal where users are having trouble.

5. Connect the technical evidence

Investigate related errors, logs, performance data, and other production signals to move from the visible symptom toward the underlying cause.

6. Investigate with your coding agent

Bring the production context into the development workflow so the investigation can start from actual evidence rather than a manually reconstructed description.

7. Fix and verify

Once the cause is identified, make the change, deploy it, and continue monitoring the relevant signals to verify that the issue has actually been resolved.

Why This Changes the Debugging Process

Most production tools are useful in isolation.

Analytics can show that behavior changed.

Session data can show what a visitor did.

Clips can reveal where users struggled.

Error tracking can show where something failed.

Logs can provide additional technical detail.

Performance metrics can show where the application became slower.

The difficult part is usually connecting those pieces.

When they are separated across different tools, debugging often becomes an exercise in manually reconstructing the story. You notice a problem in one place, search for related evidence somewhere else, collect screenshots and logs, then try to explain the whole situation to the person or agent working on the fix.

HeronSignal is built around reducing that gap.

The investigation starts with the things that need attention, moves into Insights to understand what changed, uses Sessions to inspect affected user journeys, uses Clips to identify real signs of user struggle, and connects those signals with errors, logs, performance, and the rest of the available production context.

The result is a shorter path from:

Something feels wrong.

to:

This is what changed, this is how users were affected, this is where they struggled, and this is the context needed to investigate the cause.