From PostHog Error to Session Replay on Your Phone

Why Error Tracking and Replay answer different questions

Error Tracking is strongest at grouping technical failures: the exception, stack, environment, recurrence, and affected sessions. Session Replay is strongest at sequence: what the user did, what the interface showed, and what happened immediately before and after the failure.

Neither should be stretched beyond its evidence. A stack trace does not tell you how confusing the experience felt. A Replay that shows a broken screen does not automatically identify the code path or feature flag responsible.

Used together, they help you check whether the technical failure and the customer-visible moment belong to the same story. That connection is what makes the pair valuable during a quick mobile response.

1. Start with the error, not the proposed fix

Open the error from its notification when Error alerts are enabled, or choose it from Error Tracking in Explore. Confirm that you are in the intended PostHog project, then read the error identity and scope before making a severity judgment.

Look for frequency, first and latest occurrence, affected users or sessions, release and environment context, and whether the error is still active. A dramatic stack trace with one old occurrence is a different incident from a small-looking error rising across current users.

2. Open a relevant Session Replay

If the error has an associated session, open the Replay and watch the shortest useful window around the event. Read the session context and activity before pressing play so you know which behavior you are testing.

Observe facts: the path the user took, repeated taps, a loading state that never cleared, a control that became unavailable, or navigation that changed unexpectedly. Write down what the Replay shows separately from your theory about why it happened.

3. Form the smallest testable explanation

Combine the technical and behavioral evidence into a narrow statement: “Users on release X who enter through path Y see the request fail after action Z.” That is testable. “The new feature is broken” is not.

If the evidence is incomplete, the correct mobile action may be to share the error and Replay with the owner, preserve the context, and continue on a development machine. Fast access should shorten the time to a sound decision, not force every investigation to finish on the phone.

4. Choose the response explicitly

Possible next steps include monitoring, assigning the issue, communicating with Support, or changing a feature flag your team already uses as a control. Match the action to the confidence and impact you established.

If a flag change is appropriate, identify the exact flag and expected effect, follow your team’s approval process, and verify the result after the change. Hogly does not look at a Replay and decide which flag to disable. The operator chooses because only the operator has the release and business context.

A pocket incident checklist

1. Correct project and environment?
2. Current, recurring, and affecting real users?
3. Replay evidence consistent with the error?
4. Hypothesis written as an observable statement?
5. Chosen action reversible and owned?
6. Result and handoff communicated?

The workflow is valuable even when the answer is “do not change anything yet.” Knowing that an incident can wait for deeper analysis is itself a useful operational decision.