Skip to main content
Open a problem from the Inbox to read its investigation. Timeline holds the explanation and discussion, Findings holds the recorded evidence, and Sessions shows affected user sessions. The walkthrough below uses an example: customers choosing store pickup cannot finish checkout after a release. Use the same steps with a problem in your workspace.

​
1. Find the affected app

In the Inbox, filter to the checkout surface and production environment. Open the problem describing the failed checkout. Check its first and latest detection times, affected users, and priority. Compare the first occurrence with the deployment time. A matching timestamp helps identify the release to inspect; the trace and source code will show whether that release caused the failure. First seen is the earliest evidence recorded for the problem. Last seen is its most recent occurrence. Compare them to see how long the problem has been occurring and whether new occurrences are still arriving. When a resolved problem returns as a regression, last seen advances to the new occurrence while first seen stays unchanged.

​
2. Read the investigation

Open Timeline and read the explanation. Follow its links to the supporting records. In this example, the explanation points to an exception when checkout reads shippingAddress.postalCode. The release added this access to a path also used for store pickup, where a shipping address is absent. Before accepting that explanation, check which part is supported by the evidence:
  • The exception names postalCode on an undefined value.
  • The failing stack frame points to the checkout code in the deployed release.
  • Affected sessions show customers choosing store pickup before submitting.
If the explanation does not fit the recorded behavior, use the feedback control and describe the conflicting evidence.

​
3. Open the failing trace

Open Findings, expand a day’s occurrences, and select a record. Use Jump to error in the trace to locate the failing span. Inspect the exception, stack frames, surrounding spans, release, and environment. For the pickup example, find the frame that reads shippingAddress.postalCode and check the source in that release. The same file in your current branch may already have changed. If a stack frame shows only compiled JavaScript, check source-map uploads. If the investigation cannot reference your repository, check the surface’s GitHub connection.

​
4. Check what the customer did

Open Sessions and select an affected session. Filter by a visited URL such as /checkout to narrow the list. In the replay, select the error event and inspect the actions just before it. For this example, verify that the customer selected pickup, submitted checkout, and encountered the failure. Compare another affected session to see whether it follows the same path. If a customer reported the issue directly, you can also start from their user profile or company.

​
5. Assign the fix and follow recovery

Assign an owner with A and set priority with P. Add a timeline comment linking the failing trace and the affected release. Mention a teammate when you need their input. For the example, fix the checkout path so it only requires a shipping address for delivery. Test both delivery and pickup, then deploy through your usual release process. Subscribe with S to follow updates. After deployment, check new occurrences and their releases. Interfere moves problems through recovery and resolution as it observes events. If the failure returns, a resolved problem can reopen as a regression. Dismiss a problem when your team decides it does not need action. Archive it to remove it from your working view.

​
Statuses

Release metadata connects occurrences to the code that produced them. You can also inspect the investigation through AI Agents, MCP, or the CLI.